STR #3092

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 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Bugs & Features | Roadmap 1.3 ]

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
Created By:greg.ercolano
Assigned To:greg.ercolano
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Name/Time/Date Filename/Size top right image
#1 greg.ercolano
05:15 Jun 24, 2014
#2 greg.ercolano
05:40 Jun 24, 2014
#3 AlbrechtS
10:02 Nov 18, 2023
bottom left image   bottom right image

Trouble Report Comments:

Name/Time/Date Text top right image
#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:
#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.

#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:


> 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:

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.
bottom left image   bottom right image

Return to Bugs & Features ]


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