| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3092
| Application: | FLTK Library |
|---|
| Status: | 2 - Closed w/o Resolution |
|---|
| Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | Fl_Pack: add right-to-left and bottom-to-top packing |
|---|
| Version: | 1.3-feature |
|---|
| Created By: | greg.ercolano |
|---|
| Assigned To: | greg.ercolano |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | greg.ercolano
05:15 Jun 24, 2014 |
| Suggesting a modification to Fl_Pack that adds RIGHT (for right-to-left)
and BOTTOM (bottom-to-top) packing options.
For instance, a right-to-left pack is useful to group the
right justified "Cancel" and "OK" buttons in a dialog, e.g.
___________________________________________
| Some message |
| ________ ______ |
| |_Cancel_| |__OK__| |
|___________________________________________| | |
| |
| #2 | greg.ercolano
13:16 Oct 27, 2014 |
| Not a show stopper for a 1.3.3 release. | |
| |
| #3 | AlbrechtS
10:40 Jan 05, 2017 |
| FTR: see also discussion and comments in this thread in fltk.coredev:
https://groups.google.com/d/msg/fltkcoredev/hY9hVG5v-4s/47SHMiBdq4cJ | |
| |
| #4 | AlbrechtS
14:30 Dec 06, 2021 |
| Although I voted +1 in my first comment [1] to the discussion referred to above I'm no longer convinced that this STR is a useful addition. Given **all** the problems I mentioned in the discussion I'm not sure if such an addition would not add even more problems to a widget that is problematic anyway.
Meanwhile I'm almost ready with the implementation of Fl_Grid and I'm confident that this widget can do the job requested (basically a combination of left and right alignment of widgets?) much easier and more reliably than Fl_Pack could do. Or did I miss anything?
I suggest to close this STR (or put it on hold until we know if Fl_Grid can do it) in favor of a solution with Fl_Grid - unless the patch is really good to go and works reliably.
[1] https://groups.google.com/g/fltkcoredev/c/hY9hVG5v-4s/m/BCa4DG-zYysJ | |
| |
| #5 | greg.ercolano
14:37 Dec 06, 2021 |
| I'd agree, but I'd also say put this STR on hold, in the event there's hope for also fixing Fl_Pack, as completely automated dumb/simple positioning should at least be possible. | |
| |
| #6 | greg.ercolano
14:56 Dec 06, 2021 |
| Just to add: the "appealing" thing about Fl_Pack, IIRC, is how it works in combo with a parented Fl_Scroll, making it different from any other grouping widget (even Fl_Grid?) in that it resizes itself to "shrink-wrap" around its children, so that a parent Fl_Scroll's scrollbars only appear if the pack (and its children) extend outside the Fl_Scroll's xywh area after the shrink-wrapping (resizing) process completes.
Does Fl_Grid solve this situation? If so that's interesting. I imagined Fl_Pack was kinda unique in how its size is affected in an automated way by its children. | |
| |
| #7 | AlbrechtS
10:03 Nov 18, 2023 |
| @Greg: to answer some of your questions:
> Does Fl_Grid solve this situation?
Fl_Grid can solve the situation described for a dialog window (generally spoken: any group) with mixed left and right alignment of icons, text, and buttons. I wrote a proof of concept and added it as test/grid_dialog.cxx to the FLTK repo. See:
https://raw.githubusercontent.com/fltk/fltk/f19f94d28480c28c830a38796016725585ba5ddf/test/grid_dialog.cxx
Screenshot: https://www.fltk.org/strfiles/3092/grid_dialog.png
> the "appealing" thing about Fl_Pack, IIRC, is how it works in combo with a parented Fl_Scroll, making it different from any other grouping widget (even Fl_Grid?) in that it resizes itself to "shrink-wrap" around its children...
This is IMHO the most problematic "feature" of Fl_Pack, particularly because this resizing of itself happens very late: in its own draw() method. This means that nesting other widgets inside of it (or the other way around) can cause unforeseen issues. I don't know of a solution for these issues which is the main reason why I would leave Fl_Pack as it is now rather than causing even more issues.
And no, Fl_Grid does nothing like shrink-wrapping itself around its children. Its purpose is to layout its children inside the given space (x, y, w, h) and to do this well when the Fl_Grid itself is resized in a top-down manner (resizing the window and all its nested groups). | |
| |
| #8 | AlbrechtS
10:21 Nov 18, 2023 |
| Greg, if you agree I suggest to close this STR. I don't think that your existing patch works as expected (but I didn't test it); please see my comments in fltk.coredev:
https://groups.google.com/g/fltkcoredev/c/hY9hVG5v-4s/m/a28gs-hgzMQJ
In the future I'm planning to generalize this Fl_Grid based dialog in a flexible 'Fl_Dialog' class that users can use to position their own widgets in a very flexible dialog window using grid (row/column) coordinates rather than "counting pixels" to layout their dialogs.
However, feel free to complete your work on Fl_Pack if you believe that your goals can be accomplished. This should then be posted as a GitHub issue and/or PR. Thanks for reading so far. | |
| |
| #9 | greg.ercolano
10:45 Nov 18, 2023 |
| Oh wow, I can't even remember this.
Beats me -- if Fl_Grid and friends is the right way, then we can leave Fl_Pack.
I think the mods I suggested only add features that if unused don't change old behavior. Or that was certainly the intention.
But we can close I guess.. too bad it didn't get an eval.
I can post it on my cheat page I suppose so it doesn't get lost if needed. | |
[ Return to Bugs & Features ]
|
| |
