STR #2251: Fl_Pack resize() and draw() behavior should be improved

STR #2251

Application:	FLTK Library
Status:	1 - Closed w/Resolution
Priority:	2 - Low, e.g. a documentation error or undocumented side-effect
Scope:	3 - Applies to all machines and operating systems
Subsystem:	Core Library
Summary:	Fl_Pack resize() and draw() behavior should be improved
Version:	1.4-feature
Created By:	AlbrechtS
Assigned To:	AlbrechtS
Fix Version:	None
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

No files

Trouble Report Comments:

#1	AlbrechtS 05:47 Sep 13, 2009

I'm posting this STR as a follow-up for STR #2130, so that some details won't be forgotten. In STR #2130 <http://www.fltk.org/str.php?L2130> Matt wrote: "... Fl_Pack was created to resize according to its children ... Nevertheless would it be nice to 1: fix outside resizing requests 2: obey to frame widths if a frame type is set 3: draw the box *before* we draw the children, so box types are possible too". Comments: Point 1: Fl_Pack uses its resizable() in a special way to "fill the remaining space" under certain circumstances. This may be taken into account in Fl_Pack::resize() to set some default or minimum size or such. This would probably need additional internal member variables and maybe also new methods (other than using resize). (API and ABI changes) Points 2 and 3: Fl_Pack should probably be rewritten to resize its children (and itself) in resize() and not in draw(), but there is a drawback: currently each child _can_ resize itself during its own draw() method (and the resizing code in Fl_Pack::draw() takes this into account), so that the real size of all children (the bounding box) is only known after calling draw() for all children. Thus we can't draw the box before drawing the children. Unless we use an Fl_Offscreen ? Currently I don't know a solution for the resize/draw problem. Maybe something like FLTK-2's layout() or using offscreen drawing?

#2	AlbrechtS 18:38 Jan 15, 2023

I was about to close this STR "w/o Resolution" because most of the requests can't be fixed. Fl_Pack is what it is: a "very special" widget with a special behavior. This behavior is documented and can't be changed. Points 1. and 3. above can't be fixed. Other widgets can be used instead, for instance the new Fl_Flex widget which can often be used as a drop-in replacement for Fl_Pack. Fl_Flex is similar to Fl_Pack in that it can arrange its children in a flexible way but its size is determined top-down, i.e. the group (container) sets its size. The latter is different than Fl_Pack. The only remaining point is: 2: obey to frame widths if a frame type is set I understand this that the (box) frame width needs to be subtracted to determine the available space. This needs to be investigated. However, if we can't draw the box anyway (see comment 1), then thinking about the frame size is moot. If I understood this request correctly and didn't miss anything. I changed the status to "3 - Active" and I'll look into it...

#3	AlbrechtS 08:30 Nov 17, 2023

There's nothing we can do to resolve this STR with Fl_Pack but it has been pointed out that Fl_Flex is a possible replacement that can resolve the box issues. If anything else requires a resolution please open a GitHub issue.