| [ Return to Bugs & Features | Post Text | Post File | Prev | Next ]
STR #2639
Application: | FLTK Library |
Status: | 5 - New |
Priority: | 4 - High, e.g. key functionality not working |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Core Library |
Summary: | Fl_Pack resizes hidden widgets, which it doesn't touch when visible. |
Version: | 1.4-feature |
Created By: | jcid |
Assigned To: | matt |
Fix Version: | Unassigned |
Update Notification: | |
Trouble Report Files:
[ Post File ]
Trouble Report Comments:
[ Post Text ]
|
#1 | jcid 07:52 May 22, 2011 |
| Fl_Pack resizes hidden widgets, which it doesn't touch when visible:
The tiny example program illustrates the point:
* resize the window back and forth and both "Group 1" and "Group 2" keep their heights. OK here. * With a small window, hide "Group 2" and resize to a big window, then show "Group 2". It grew while hidden!?
This bug makes it hard to find a way to code a hideable UI panel. There're workarounds but they're not easy to find as the docs don't shed light on it.
Workaround examples:
1) remove Group2 after hiding, re-insert on show. 2) resize Group2 to 0,0 upon hide, then resize again upon show.
It'd be great to have a simple and obvious way to do it. | |
|
#2 | AlbrechtS 14:42 May 23, 2011 |
| I can't replicate your problem. Your example program behaves well in my tests on Linux and Windows (G2 keeps its size). I also tried to comment the g3->size(...) lines, but still no luck. Did you upload the wrong demo program? | |
|
#3 | AlbrechtS 14:44 May 23, 2011 |
| Side note to Matt: it is not clear if we have a bug or not. If yes, then its severity is minor, hence it shouldn't stop the next RC. | |
|
#4 | matt 15:47 May 23, 2011 |
| This sounds incredibly familiar. I thought I fixed this three months ago?! Or it wasn't really a ug, or something. Boy, I am getting old :-/ . | |
|
#5 | chris 04:09 May 24, 2011 |
| I can repeatably reproduce it with latest svn, but only when following exactly this sequence:
- hide g2 - resize window vertically - show g2 | |
|
#6 | ianmacarthur 05:15 May 24, 2011 |
| I can reproduce it sometimes, using Chris's recipe, but not consistently. (On WinXP.)
There is something messed up in the resizing though, but I can't quite describe what.
I've never been a fan of Fl_Pack anyway...! | |
|
#7 | jcid 05:44 May 24, 2011 |
| Hi,
I'm running on Ubuntu GNU/Linux, fltk-1.3-rc5, and re-checked the uploaded program to be the right one (download/fresh compile). I wrote Matt about this a couple of months ago. Funny how he also couldn't reproduce it in the first try, but succeeded later:
[Matt wrote:] > [jcid wrote:] > > It's even possible to continue growing/shrinking using the same > > trick. e.g.: > > > > 1.- start with a small window > > 2.- hide "Group 2" > > 3.- maximize window > > 4.- show "Group2" > > 5.- shrink window to original size > > 6.- hide "Group 2" > > 7.- maximize window > > 8.- show "Group2" > > > > Here, "Group 2" has grown near four times in height. > > OK, now I see something too. The maximizing did the trick. It > seems that g2, when hidden, lies within the area of the > resizable. So when it is shown again, the entire "resizable" > mechanics are messed up. Now that I can replicate the issue, I > will fuz around with it for a bit an let you know when I get an > idea. The most likely correct solution will be to manually > recalculate the g3 position and sizes when you show or hide g2, > and the call init_sizes().
After a deeper analysis, he came with this detailed diagnose:
> [Matt wrote] > OK, I think I am getting there: the gist of it is this: Fl_Pack > does not have a resize() function at all, so resizing it will > fall back to Fl_Group::resize() which correctly resizes all > widgets, visible or not, to keep the integrity of the layout. > > Fl_Pack however recalculates the widget layout during > Fl_Pack::draw(). At this point, Fl_Group::resize() has already > resized your G2 because it clearly is within the range of the > resizable(). > > I did the following changes in your code: > > static void b1_cb(Fl_Widget *w, void *data) { > Fl_Group *g2 = (Fl_Group *)data; > > if (g2->visible()) { > g2->hide(); > g3->resize(g2->x(), g2->y(), g3->w(), g3->h()+g2->h()); > p1->init_sizes(); > g2->window()->redraw(); > } > } > > static void b2_cb(Fl_Widget *w, void *data) { > Fl_Group *g2 = (Fl_Group *)data; > > if (!g2->visible()) { > g3->resize(g3->x(), g3->y()+g2->h(), g3->w(), g3->h()-g2->h()); > g2->show(); > p1->init_sizes(); > g2->window()->redraw(); > } > } > > An also added a resize function to F_Pack. It is very simple > because Fl_Pack::draw() does the actual layout, as mentioned > above. > > protected: > void draw(); > void resize(int X, int Y, int W, int H) { > int dx = X-x(), dy = Y-y(); > int dw = W-w(), dh = H-h(); > Fl_Widget::resize(X, Y, W, H); > Fl_Widget *r = resizable(); > if (r && r!=this && (dw || dh)) { > r->size(r->w()+dw, r->h()+dh); > } > // let redraw() do the rest of the layout process > if (dx || dy || dw || dh) > redraw(); > } > > > Maybe we should propose to add this to Fl_Pack? This is the time > to break such things, before we release 1.3! > > What do you think? Also, does this solve the issue?
And yes it solved the issue, but OTOH, the workarounds were simpler, and at this point it was clear that something was going wrong in the resize mechanics of Fl_Pack.
HTH | |
|
#8 | matt 06:10 May 26, 2011 |
| Sorry, now it's too late for such a major change in behavior. I will bump this with high priority though. | |
|
#9 | jcid 14:29 May 30, 2011 |
| Hi,
FWIW, it turns out that Fl_Group also does strange things upon resize. The second attached program (gr_rsc.cc) shows this:
1.- <start program> 2.- hide g2 3.- maximize window 4.- show g2
g2 has increased in height! Again, its height doesn't increase upon maiximize when it is visible.
I left init_sizes() calls commented in different parts of the hide/show callback code. Enabling them by pairs produces weird effects. I don't know which of these effects is intended, but I found no reference to them in the docs, so at least some of them may be a bug.
As Matt plans to fix this STR before rc7, the new example was uploaded in the hope it helps the cause. | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |