| |
| |
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();
}
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/d4f25673-c448-602c-b0ee-7814102b4a80%40online.de.
[ Direct Link to Message ] | |
|
| |
