| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3030
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 3 - Moderate, e.g. unable to compile the software |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | resize behavior of widgets in an Fl_Tree |
|---|
| Version: | 1.3-current |
|---|
| Created By: | geuzaine.acm.caltech |
|---|
| Assigned To: | AlbrechtS |
|---|
| Fix Version: | 1.5.0 |
|---|
| Fix Commit: | 1377c60100f6adfbb8ac72701afcb58e0533df13 |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | geuzaine.acm.caltech
05:35 Jan 16, 2014 |
| The resize behavior of widgets in an Fl_Tree is (seems?) strange.
1) Compile and launch the attached example (test_tree.cxx). A push button is associated with each tree item. The result looks like this:
+[==========]
+[==========]
[==========]
[==========]
2) Resize the window by repetitively extending and reducing its width. After a few iterations, the widgets look like this:
+[==========]
+[=======]
[====]
[====]
Is this the expected behavior? (Probably due to the proportional resizing of the widgets inside Fl_Groups of varying widths?) | |
| |
| #2 | greg.ercolano
23:39 Jan 26, 2014 |
| Assigning to me.
Will see if I can define more predictable default resize behavior.
FWIW, I'd suggest defining a group around each button,
and use widget() to add the group instead of the button,
like the test/tree.cxx example does.
Attaching a modified version here which keeps the buttons
all the same size. | |
| |
| #3 | greg.ercolano
10:27 Feb 17, 2014 |
| Attaching tree-with-resizable-option.cxx which has features useful
for debugging this.
Apparently the strange sizing, if exercised enough, stabilizes
to reveal the widths being /opposite/ of what they should be;
items indented more end up having longer lengths than they should.
This is because the Fl_Group still has an internal copy of the
x/y positions of the widgets at the time they were created.
When the widgets are created, we set the widget's X/y positions
all to 0 because we know the tree will handle actual positioning
of them so that they appear in the tree in their proper place.
What's happening is when the tree repositions the X/Y position of the
widgets, the Fl_Group()'s internal buffer still has the original
x,y positions of the widgets (0,0) buffered, which need to be reset
by a call to init_sizes().
But we don't want to call init_sizes() very often, because then
it will accumulate integer rounding errors when the tree is resized.
Seems like the tree needs to keep Fl_Group informed of the constant
widget repositioning that happens, but in such a way that it avoids
integer round off from calling init_sizes() too often.
Currently Fl_Group offers us the protected sizes() method to access
Fl_Group's internal positioning buffer, so Fl_Tree can probably directly
manipulate that so Fl_Group::resize() behaves the way we want.
Researching that.. | |
| |
| #4 | greg.ercolano
13:34 Oct 27, 2014 |
| Unresolved state of this STR should probably not affect 1.3.3 release. | |
| |
| #5 | AlbrechtS
11:56 Apr 07, 2026 |
| Fixed in master (1.5.0).
commit 1377c60100f6adfbb8ac72701afcb58e0533df13
Date: Tue Apr 7 20:29:42 2026 +0200
Fl_Tree: make automatic resizing of children optional (STR 3030)
- add getter and setter methods:
- int Fl_Tree::auto_resize_children()
- void Fl_Tree::auto_resize_children(int mode)
Note: the default in 1.5.0 is "OFF", i.e. no automatic resizing.
The methods above can be used to switch it on if required.
This is a behavioral change to fix a bug in 1.4 and lower. It will not
be backported because it would break the ABI.
--- end of commit log ---
I chose this approach because:
(a) the resizing behavior of children was not documented [1]
(b) the current behavior led to unexpected and unpredictable results
(c) an option to select the behavior by the user of the library is useful anyway.
Basically there's still room for improvement by defining another `mode` value for the
`auto_resize_children(int mode)` method but that's OT here.
@Greg: I'll post another test program here that can be used to show the effects of
auto resizing better. The default value is disputable, but I believe that disabling
the resizing behavior is the better choice. IMHO container widgets like Fl_Tree
should define and document their specific resizing behavior and not rely on
Fl_Group::resize(). But I'm open for discussion on the usual channels
(fltk.development or GitHub Discussions). I'm closing this STR now.
-----
[1] docs about resizing still to be done. | |
| |
| #6 | AlbrechtS
12:02 Apr 07, 2026 |
| Fixed in Git repository.
Closed. If there are other issues please open a GitHub Issue or discuss in fltk.general or fltk.coredev. | |
[ Return to Bugs & Features ]
|
| |
