[ Return to Bugs & Features | Roadmap 1.3 ]

STR #3092

Trouble Report Files:

	Name/Time/Date	Filename/Size
	#1  greg.ercolano 05:15 Jun 24, 2014	pack-diff-v1.patch 7k
	#2  greg.ercolano 05:40 Jun 24, 2014	test-pack-v1.cxx 2k
	#3  AlbrechtS 10:02 Nov 18, 2023	grid_dialog.png 17k

Trouble Report Comments:

	Name/Time/Date	Text
	#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 ]