One thing is that certain drawing primitives do not obey the transformation matrix. Not sure how much incompatibility it would introduce that all drawing functions would obey the matrix (images at least translation coefficients), then you can set the matrix before drawing children:
fl_push_matrix(); // to be sure that children do not mess wit the matrix fl_translate(x(), y()); draw_children(); fl_pop_matrix(); In your widget, if you prefer to draw relative to the widget coordinates, you could always do the same at the beginning of your draw() function, still keeping backward compatibility. But that transformation would need to be synchronised with event delivery: should events (Fl::event_x(), F;::event_y(), ...) obey some transformation? I would say is YES, definitely. Maybe we can have a compromise for backward compatibility: groups would use another bit within the flags(defaulting to 0), maybe even with a special access method like Fl_Group::root() and - when the flag is non-zero - it would do sequence above and also similar things before delivering events. The event matrix would need to be either inverse or to global events would need to be multiplied by inverse of drawing matrix to transform to local coordinates Fl::event_x() and Fl::event_y(). As long as the groups do only translations (and only *int* values for that matter), the more tricky parts (scaling fonts, line thickness, images) could be left for ... later. R. On 09/06/2011 16:48, Matthias Melcher wrote: > That is precisely the plan. This leftover has lead to many > misunderstandings... > > On 09.06.2011, at 17:12, Marcel Dejean <[email protected]> wrote: > >> On Thu, Jun 9, 2011 at 5:06 AM, MacArthur, Ian (SELEX GALILEO, UK) >> <[email protected]> wrote: >>> >>> At some point, fltk-3 will offer a choice... >>> >> >> Seeing as the primary reason for this behavior in FLTK1 was for >> backwards compatibility with Forms and the far more common behavior is >> parent-relative coordinates (plus when would you *not* be referencing >> x() and y()?), I would expect FLTK3 to use parent-relative coordinates >> and only provide the old system in the FLTK1 compatibility layer. >> >> _______________________________________________ >> fltk mailing list >> [email protected] >> http://lists.easysw.com/mailman/listinfo/fltk > _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
