Re: Re: Drawing Review / RFCs

On Tue, 2003-09-16 at 06:21, Marc Str=C3=A4mke wrote:
> Darren V Hart wrote:
> > Team,
> >=20
> > First, my code review of Marc's updated drawing mechanism:
> >=20
> > 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::dra=
w
> > is now a one liner?
> basicly i did this show how our coding in c++ should be done, basicly=20
> what we are doing everywhere else isnt really clean c++. Using an extra=20
> function that works on a container, and calling it with a standard=20
> algorithm like for_each or transform is IMHO the only really clean way=20
> to use c++, because the for_each cleanly communicates to the programmer=20
> reading the code, what it does. Most of the time using extra routines is=20
> an elegant solution to this, if you only do simple things, boost::lambda=20
> might come into a neat use there *g* :) Whatever, just a quick rant=20
> about style *g*, i dont want to put something like that in our coding=20
> style convention because you cant really describe with rules, when each=20
> style is more appropiate, but for example using an integer to iterate=20
> trough a vector is totally wrong, because you then rely on a specific=20
> type of container instead of beeing generic!
>=20

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.=20
Are you sure you don't like that hammer of yours just a little too
much?  *grins*

> >=20
> > 2) container::draw_child line 87 (after CVS update)
> >     clip rect is in world coords, child's rect is local coords so the=20
> >     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=20
> simplifies the stuff greatly so i thought a change there would be appropi=
ate
>=20
> >=20
> > 3) All in all I thought the flow of the drawing mechanism is much
> > improved and very elegant.  Nice work Marc.
> thx!
>=20
> >=20
> >=20
> >=20
> > Second, some design issues I would like to get everyone's thoughts on:
> >=20
> > 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 rectangl=
e
> > class changes.  Would anyone object terribly if widget derived from
> > rectangle?
> >=20
> > 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?
> >=20
> > 3) Should state be focusable? (it isn't atm)
> >=20
> > 4) Where should events go if there is no focused widget?
>=20
>=20
>=20
>=20
> _______________________________________________
> Libstk mailing list
> [email protected]
> http://www.dvhart.com/cgi-bin/mailman/listinfo/libstk