| | [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #2130
| Application: | FLTK Library |
|---|
| Status: | 2 - Closed w/o Resolution |
|---|
| Priority: | 3 - Moderate, e.g. unable to compile the software |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | The contents of an Fl_Pack disappear when it is shrunk too much. |
|---|
| Version: | 1.1.9 |
|---|
| Created By: | jeremy_henty |
|---|
| Assigned To: | AlbrechtS |
|---|
| Fix Version: | Will Not Fix |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | jeremy_henty
06:40 Jan 21, 2009 |
| Compile the attached file and shrink the main window vertically. After a while the box disappears. It reappears when you enlarge the window again. It looks as though the contents vanish whenever the main window has shrunk by an amount larger than their height.
The same bug is present if you create a horizontal pack and shrink the main window horizontally.
Demonstrated on Linux 2.6.27.10, gcc 4.1.2, X.org 7.2, FLTK 1.1.9. | |
| |
| #2 | matt
09:08 Feb 05, 2009 |
| Yes, this is verified. I think we always used Fl_Pack inside a Scroll which behaves just fine, but interactively resizing an Fl_Pack does not work.
OTOH, the Fl_Pack was created to resize according to its children, not to a parent, so it is not used in the intended context here. 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 | |
| |
| #3 | AlbrechtS
13:10 Jul 07, 2009 |
| I posted two files:
[1] http://www.fltk.org/strfiles/2130/Fl_Pack_1.diff
[2] http://www.fltk.org/strfiles/2130/pack.cxx
#1: Fl_Pack didn't obey Fl_Group::clip_children(). This fix is necessary for the demo program pack.cxx.
#2: The demo pack.cxx is an extended version of the OP's pack.cc file (compile with fltk-config --compile pack.cxx). I added the x/y/w/h coordinates before Fl_Pack::draw() (left side) and the w/h values after draw() (right side). Some boxes and lines (e.g. a white background box) are for testing only.
This is not a fix yet, but the effect can be seen better. Look for the w and h values on the left side (before draw): they become negative if the window is being shrunk enough!
The clip button works only after applying [1] and shows a much better behavior.
I'll start a discussion "RFC: Negative widget width and/or height ?" in fltk.development about the aspects of negative width and height... | |
| |
| #4 | matt
03:04 Sep 13, 2009 |
| Albrecht, please apply your patch and promote the rest of the issue to 1.3. Thanks! | |
| |
| #5 | AlbrechtS
05:24 Sep 13, 2009 |
| Fixed in Subversion repository.
To the OP: The behavior you see happens, because you shrink the window too much for the resizable to be visible at all. Its height becomes negative, and this is undefined behavior. The correct solution for this is to set a size_range() for the window that covers at least the range below and above the resizeable widget (or left and right of it, resp.), so that this does not get resized to a negative size. The fact that the Fl_Pack widget disappears *suddenly* only has to do with its property to resize itself always to the size of its children.
The proposed patch *MUST NOT* be applied, because Fl_Pack resizes itself during drawing of its children, and clipping the children doesn't work, because Fl_Pack can't know the real size in advance.
This, as well as the proposed "features" (Matt, Feb. 05, 2009) can't be implemented in FLTK 1.1 because of implementation details (resizing of widgets during draw()). I'll open another STR for "1.4". | |
| |
| #6 | AlbrechtS
05:26 Sep 13, 2009 |
| Correction: Sorry for the wrong message "Fixed in Subversion repository". This doesn't apply, obviously. | |
| |
| #7 | AlbrechtS
10:36 Sep 13, 2009 |
| Please see also STR 2251 for more.
http://www.fltk.org/str.php?L2251 | |
[ Return to Bugs & Features ]
|
| |
