> > A lot of it was due to Forms compatibility, as it did it this way. > > > > There was an attempt to fix this in fltk2. > > Fix it, as in use global coordinates? Though I've been bitten by this > local coordinates thing, Greg's explanation made some sense to me. It > would be a hassle to update every widget whenever the window was > dragged.
No, more "fix it, as in use enclosing-group-or-window-local co-ordinates" so that the user would only ever set widget co-ords WRT the widgets immediate parent container. The kicker here being that although group and window are "the same" in many ways, widget co-ords within a window have 0,0 at the window origin, whereas within a group they are referenced to the window that ultimately encloses the group, which may be many "parents" away... The intent is to make all containers the same (i.e. window-like) so that layout within a group/window/other-container is consistent. The fltk lib would then deal with ensuring this container-local frame was correctly mapped to the global co-ordinate space, of course. This approach is what most users appear to expect, and seems to be, de facto, the Way Things Are Usually Done These Days, AFAICT. SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
