| [ Return to Bugs & Features | Post Text | Post File | Prev | Next ]
STR #2251
Application: | FLTK Library |
Status: | 3 - Active |
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: | Unassigned |
Update Notification: | |
Trouble Report Files:
[ Post File ]No files
Trouble Report Comments:
[ Post Text ]
|
#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... | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |