A lot of it was due to Forms compatibility, as it did it this way. There was an attempt to fix this in fltk2.
On 06/10/2011 12:34 PM, Greg Ercolano wrote: > On 06/10/11 11:54, Evan Laforge wrote: >>> ..we probably need to go into some details in the "Drawing Things in FLTK" >>> section about how the coordinate space works for widgets vs. windows. >> >> Speaking of which, why is it that way in the first place? > > I think it was mainly a speed issue, to allow widget drawing > code to go as fast as possible, and not have to worry about > one widget relative to another in large hierarchies. > > FLTK is basically exposing the way drawing is actually > handled by the base libraries (xlib, win32) where all coords > are relative to the corner of the window. > > I believe Bill cited this in his original documentation > which may not have survived to the to the current incarnation > of the docs, not sure. (Perhaps he went into these details > in old forum postings, not sure) > > It was, IIRC, a design issue where he wanted drawing > to go as fast as possible (the F in FLTK), and not get > caught up in having to convert offsets for all x/y coords > used in drawing, and having to maintain these offsets > throughout the widget hierarchy when widgets are moved around. > > I recall he even went into details that the widget would > know best about how to handle drawing details esp. in the > context of resizes, or during resizing/repositioning of > widgets. > > I believe he also cited the devil was in the details > of maintaining these offsets in the context of widget > resizing, and could cause the internals of the widget lib > to take long excursions to maintain these values. > > All of this was apparently avoided by simply not trying > to do all that work by default, and simply expose the > way the window manager presented the coordinate space > to all widgets, where their own logic could determine > the best way to handle drawing. > > Bill can probably put it in better words, as I recall > it was something he did very much on purpose in the > original FLTK design. Hope I'm remembering this correctly..! _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
