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

STR #2639

Trouble Report Files:

	Name/Time/Date	Filename/Size
	#1  jcid 07:52 May 22, 2011	rsz.cc 2k
	#2  jcid 14:20 May 30, 2011	gr_rsz.cc 2k

Trouble Report Comments:

	Name/Time/Date	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 ]