Subject: growing windows bug fixed :)

From: Dominik Vogt <[email-masked]>
Date: Tue, 8 Dec 1998 02:29:56 +0100

Hi all,

with the hint from Tomas (thanks Tomas!!) I was able to
track down and eliminate the bug that has given us so much
trouble. The stroy went like this:

In resize.c there were static variables constrainx and
constrainy that were used to give some obscure parameter
to the function ConstrainSize. I guess ConstrainSize was
static too once ago, but since it has been used from
various files (event.c, builtins.c and add_window.c).

So when you resize e.g. FvwmButtons, constrainx/y are
set to the appropriate windows. Now you add a window
and ConstrainSize is called from somewhere in add_window.c.
Now it uses the old values from FvwmButtons... boom.

constrainx/y come directly from the windows's size hints,
but in one situation both are set to zero. I introduced
a new parameter to ConstrainSize to handle this case that
occurs only once. I don't like this patch very much, since
it is a bit dirty and may lead to problems in the future,
but the matter seems to be too complicated to fix now.

In events.c I finally found the reason for all this
commotion (HandlePropertyNotify(), lines 563-571):

      /*
      ** ckh - not sure why this next stuff was here, but fvwm 1.xx
      ** didn't do this, and it seems to cause a bug when changing
      ** fonts in XTerm
      */
  #if 0
      new_width = Tmp_win->frame_width;
      new_height = Tmp_win->frame_height;
      ConstrainSize(Tmp_win, &new_width, &new_height, False);
      if((new_width != Tmp_win->frame_width)||
          (new_height != Tmp_win->frame_height))
          SetupFrame(Tmp_win,Tmp_win->frame_x, Tmp_win->frame_y,
                     new_width,new_height,False);
  #endif /* 0 */

So it seems Chuck has removed old code that fixed the
problem but created another bug with xterm :(

Anyway, although I believe the problem is fixed, please
keep your eyes open. There might be another problem that
still remains.

Bye

Dominik
-- 
Dominik Vogt, [email-masked]

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Tim Phipps <[email-masked]>
Date: Tue, 08 Dec 1998 11:07:20 +0000

This bug is my fault. Hope I didn't make your head hurt too much Dominik.

Dominik Vogt wrote:

> to the function ConstrainSize.

I was trying to stop focus changing after a resize.  What used to happen
was that in an interactive resize of an xterm the pointer was always
outside the rubberband because ConstrainSize always made the width =
(width / increment) * increment. i.e. rounded down to the nearest resize
increment. When you finished the resize the pointer would be outside the
window and if there was a PointerFocus window below it the focus would
change.
This drove me nuts so I changed the interactive case to ((width + inc -
1)/inc) * inc.  I don't know why I used statics (just being a Wally
probably), your patch is the right way.

> but the matter seems to be too complicated to fix now.

My intention was that constrainx/y should always be zero except for
interactive resizes.  I had a look at your patch and I think you have it
backwards but I don't think it will matter as programs shouldn't ask for a
size that isn't a multiple of the increment.
If they do their size will be rounded up.  If you want I can change it to
the old style (rounded down) but I don't think it matters.  It may be a
problem if fvwm ever tried to limit the size of windows in which case you
would want rounding down.

> problem but created another bug with xterm :(

I don't think this is the reason for all this.  I don't know what this bit
of code is intended for but maybe xterm is asking for the wrong size or
it's not changing the size at the same time as changing the resize
increment.  The ICCCM says that apps shouldn't change their wmhints when
mapped so xterm should really do an unmap, change font, map sequence.  It
would look awful and would probably cause it to pop to the top so it's
best left.

Cheers,
Tim.

PS anyone would think that I'm getting paid by a certain software company
to discredit the open source movement.  It's not true, it's just a natural
talent I have ;-)

---

From: Tim Phipps <[email-masked]>
Date: Tue, 08 Dec 1998 15:13:32 +0000

> would want rounding down.

Of course almost as soon as I wrote this I remembered that fvwm does limit
sizes when maximizing.  Version 1.9 of resize.c will make maximized xterms
larger than the screen size.  I'll fix this now.

Cheers,
Tim.

PS what's the difference between FALSE and False, TRUE and True? Which is
best?

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 8 Dec 1998 16:51:56 +0100

> PS what's the difference between FALSE and False, TRUE and True? Which is

False and True are defined by X for variables of type Bool.
In the end I don't think it matters, but I'd prefer using
False/True always (although I don't do it myself).

Bye

Dominik
-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].