[ Return to Bugs & Features | Roadmap 1.3 | Post Text | Post File | Prev | Next ]

STR #3030

Trouble Report Files:

	Name/Time/Date	Filename/Size
	#1  geuzaine.acm.caltech 05:35 Jan 16, 2014	test_tree.cxx 1k
	#2  greg.ercolano 23:40 Jan 26, 2014	tree-with-fixed-sized-buttons.cxx 1k
	#3  greg.ercolano 10:27 Feb 17, 2014	tree-with-resizable-option.cxx 2k

Trouble Report Comments:

	Name/Time/Date	Text
	#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.

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