On 11/27/20 3:27 AM Greg Ercolano wrote:
> On 2020-11-26 17:59, Albrecht Schlosser wrote:
>> Here's a thought that *could* work: long ago I created a commercial
>> application that used group relative coordinates in its own
>> window/group/widget definition syntax. These internal group relative
>> coordinates wer transformed to FLTK window relative coordinates when the
>> widgets were created.
>>
>> What we could do is a similar approach: we could use a flag that lets
>> the user create a widget with group relative coordinates and we could
>> transform the widget coordinates to window relative coordinates when the
>> widget is add()ed to the group. This flag could either be global or used
>> in a modified Fl_Group::add() method.
>> [..]
>> Might be worth some further investigations...
>
> Interesting -- and if Gonzalo's issue is a concern worth addressing (confusion over absolute vs. relative),
> it could be a subclass, e.g. Fl_Group_R or Fl_Group_Relative or some such. We certainly have cases
> where a whole class is used just to set a flag (e.g. Fl_Output).
These classes (like Fl_Output) are only a few exceptions, but your idea
would concern all classes. Inheritance would be a mess. Think of
Fl_Tabs_R: what should be its base class, Fl_Group or Fl_Group_R ? And
so on, this is only a very simple example.
> I guess the good thing though about using the transforms in draw() is that interrogating the children's
> xywh values while in the group would retrieve the same values they were created with.
Hmm, I can't see the "good thing" in this. Honestly.
Whenever you resize the window or a group within the window all
contained widgets get new x/y/w/h values anyway. I'd say this (returning
relative coordinates) would be more confusing than good.
> I wasn't sure if transforms were fully implemented, as I don't think they affect /all/ fltk drawing code,
> just some, but perhaps that's been fixed during the recent mods for drivers and scaling.
I'm 99.9% sure that the driver stuff didn't change the fact that the
transformations are not obeyed by all drawing functions.
<tl;dr>
In a very simplified form the implementations of drawing functions have
"only" been moved to different source files. Instead of:
void fl_draw_something() {
#if defined(_WIN32)
// platform specific implementation here
#elif defined(__APPLE__)
// platform specific implementation here
#else
// platform specific implementation here
#endif
}
we have now:
void fl_draw_something() {
fl_graphics_driver->draw_something();
}
with draw_something() being implemented in platform specific source
files as virtual driver methods and fl_graphics_driver being the current
platform specific graphics driver. The implementation was not affected
by this move.
</tl;dr>
> Certainly it's useful to be able to create widgets relative to the upper-left of the parent that is not a window;
> doing form layouts in fluid that are then procedurally instanced in a scroll is one of many I can think of.
> I usually have to go in after and apply x/y offsets.
I agree that this would be a useful addition, but I believe that the
internal storage of x/y coordinates should not be changed for several
(implementation) reasons and "F" (fast) property of FLTK.
I believe the only thing needed would be an option to create widgets
with x/y coordinates relative to their parents and to add() or insert()
widgets into groups with x/y relative to their group (parent) coordinates.
This would probably require new constructors (for /all/ widgets) with a
flag to use x/y as relative to their parents, as in
// main()
const int rel = 1;
Fl_Window win(400, 400);
Fl_Group grp(50, 50, 300, 300);
Fl_Box box(10, 20, 80, 80, rel, "label");
so we can also support static constructors as shown above. In this case
x/y of box would be relative to its parent grp, i.e. x = 60, y = 70.
If you want to get relative coordinates of widgets you can (alreay now) use:
int rel_x = box.x() - box.parent()->x();
or we could easily add
int Fl_Widget::rel_x() {
if (parent())
return x() - parent()->x();
else
return x();
}