Re: Drawing Review / RFCs

Darren V Hart wrote:
> Team,
> 
> First, my code review of Marc's updated drawing mechanism:
> 
> 1) updating surface::offset in component::draw_child is nice, it
> simplifies the individual widget draw routines, very nice.  I am not
> sure why we added draw_child as a separate routine since container::draw
> is now a one liner?
basicly i did this show how our coding in c++ should be done, basicly 
what we are doing everywhere else isnt really clean c++. Using an extra 
function that works on a container, and calling it with a standard 
algorithm like for_each or transform is IMHO the only really clean way 
to use c++, because the for_each cleanly communicates to the programmer 
reading the code, what it does. Most of the time using extra routines is 
an elegant solution to this, if you only do simple things, boost::lambda 
might come into a neat use there *g* :) Whatever, just a quick rant 
about style *g*, i dont want to put something like that in our coding 
style convention because you cant really describe with rules, when each 
style is more appropiate, but for example using an integer to iterate 
trough a vector is totally wrong, because you then rely on a specific 
type of container instead of beeing generic!

> 
> 2) container::draw_child line 87 (after CVS update)
>     clip rect is in world coords, child's rect is local coords so the 
>     child->intersection call will not behave as expected for nested
>     containers (I believe, Marc?).
No, i changed clip rect to be in local coords for this to work, it 
simplifies the stuff greatly so i thought a change there would be appropiate

> 
> 3) All in all I thought the flow of the drawing mechanism is much
> improved and very elegant.  Nice work Marc.
thx!

> 
> 
> 
> Second, some design issues I would like to get everyone's thoughts on:
> 
> 1) All widgets have a rect, but it is tiresome to do
> widget.rect().rect_method().  We currently wrap the rect methods in
> widget, but that is burdensome and a pain to maintain when the rectangle
> class changes.  Would anyone object terribly if widget derived from
> rectangle?
> 
> 2) Do the widget draw routines really need to receive the surface as a
> parameter since they all derive from drawable and hence have a surface()
> method?
> 
> 3) Should state be focusable? (it isn't atm)
> 
> 4) Where should events go if there is no focused widget?