STR #2251

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

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]

No files

Trouble Report Comments:

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


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

Return to Bugs & Features | Post Text | Post File ]


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 ''.