Re: 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?
> 
> 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?).
> 
> 3) All in all I thought the flow of the drawing mechanism is much
> improved and very elegant.  Nice work Marc.
> 
> 
> 
> 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?
I dont really think using widget.rect() is tiresome, the only really 
good thing to do would be to privately inherit from rectangle, because a 
widget doesnt really "is a" rectangle. I would be ok with both solutions 
though, it's your decision :)

> 
> 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?
I think the most important question is, does drawable need a surface() 
function?

> 
> 3) Should state be focusable? (it isn't atm)
Good question, basicly i dont  care about focus atm because it is quite 
unimportant for my touchscreen *g*, but i think it might be wortwhile 
for the user to get events from the state, if no widget is focused, so 
basicly the state might get focus if no other widget is focused.

> 
> 4) Where should events go if there is no focused widget?
see above



btw, thx for the review :)