STR #2639

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 | 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:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size top right image
 
#1 jcid
07:52 May 22, 2011
rsz.cc
2k
 
 
#2 jcid
14:20 May 30, 2011
gr_rsz.cc
2k
 
bottom left image   bottom right image

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
 
#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.
 
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-2021 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.