STR #3030

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 | Roadmap 1.3 | Post Text | Post File | Prev | Next ]

STR #3030

Application:FLTK Library
Status:4 - Pending
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
Created By:geuzaine.acm.caltech
Assigned To:greg.ercolano
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size top right image
#1 geuzaine.acm.caltech
05:35 Jan 16, 2014
#2 greg.ercolano
23:40 Jan 26, 2014
#3 greg.ercolano
10:27 Feb 17, 2014
bottom left image   bottom right image

Trouble Report Comments:

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