FLTK logo

Re: [fltk.coredev] RFC: Fl_Group option with relative coords for children

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.coredev  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: RFC: Fl_Group option with relative coords for children Greg Ercolano Nov 26, 2020  
 
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).

    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.

    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.

    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.


-- 
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/73ea446f-d2ff-434d-58c2-a6d8a0705449%40seriss.com.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.