Re: Drawing Review / RFCs

Darren Vincent Hart wrote:
> On Tue, 2003-09-16 at 06:21, Marc Strämke wrote:
> 
>>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!
>>
> 
> 
> While we are ranting.. *g*
> I agree we shouldn't use an int to walk through a vector, however, IMO a
> for loop on .begin() through .end() communicates the intent every bit as
> well as for_each and is still generic.  Since there are only a few lines
> of code to be executed during each iteration, the extra (albeit minimal)
> effort in calling another function is superfluous IMO.  It seems to me
> that you are now arguing the other side of the drawable::ptr argument. 
> Are you sure you don't like that hammer of yours just a little too
> much?  *grins*
Ignoring your last few sentences -> For_each has still the added 
advtange tht you dont need to know anything about the type of iterator 
you're using etc, its simply the cleanest way, thats why i said that i 
dont want to include that in any coding standards or anything, i just 
think for many uses (most) it is the cleanest way to iterate trough a 
container
> 
> 
>>>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?
>>
>>
>>
>>
>>_______________________________________________
>>Libstk mailing list
>>Libstk@Óq«LD—"
>>http://www.dvhart.com/cgi-bin/mailman/listinfo/libst
> 
> k