Subject: FVWM: Probably a bug - FVWM 2.5 CVS - XTerm geometry and font resize

From: Tom Alsberg <[email-masked]>
Date: Tue, 7 May 2002 16:53:59 +0300

Hi there.
I am using FVWM 2.5.2 (current CVS, as of 2002/05/06, but it happened
before too), and there seems to be a problem - when changing the fonts
in a running XTerm, i.e. with Shift + Keypad Plus (KP_Add), Shift +
Keypad Minus (KP_Subtract), or the Control + Right click menu, when
the font resizes, the geometry (that is - in characters - lines and
columns) of the XTerm also changes somewhat.

For example, with default XTerm (no custom X resources), it starts
80x24. If I then change the font to Large, the geometry changes to
120x27. When I then change the font to back to Default, the geometry
changes to 80x23 (not back to 80x24).

This happens only with CVS FVWM 2.5, it doesn't happen with FVWM
2.4.6, or with any other window manager, like TWM/MWM/Enlightenment.

No special FVWM configuration is needed to reproduce the problem - it
happens also with no .fvwm2rc at all.

Any idea what the problem might be?
It seems to me like a bug in CVS FVWM, as it does not happen with FVWM
2.4, or with other window managers, and it happens also without any
custom X resources (xrdb -remove) and without a custom FVWM
configuration.

  Any help/fix appreciated, thank you,
  -- Tom  

-- 
  Tom Alsberg - certified insane, complete illiterate.
        e-mail: <[email-masked]>
	Homepage: http://www.cs.huji.ac.il/~alsbergt/
  * An idea is not responsible for the people who believe in it.
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 7 May 2002 16:36:13 +0200

> custom X resources (xrdb -remove) and without a custom FVWM

It's not really a bug in fvwm, but a combination of bugs in xterm
with a lack of functionality in X.  When an application changes
its font size, the window manager is informed that the font size
has changed, but not to which height and width.  So, fvwm looks up
that information on its own - but at the time it get to it, the
size may already have changed again.  For exampe:

 - Start with font width 9x15, window is 90 by 15 pixels (10x10)
 - App changes its font size to 10x18
 - App resizes its window to 100x180 (10x10)
 - App changes its font size to 12x24

If all requests are sent one by one to the X server and fvwm
processes them before the next is issued, the resulting window
will be 120x240 pixels (10x10).  If all requests are sent to the
X server before fvwm handles them, this happens:

 - Fvwm gets a PropertyNotify event indicating the font size has
   changed.
 - Fvwm reads the font size (12x24) and resizes the window to
   120x240 (10x10).
 - Fvwm reads the resize request and resizes the window to
   96x168 (8x7).
 - Fvwm ignores the next PropertyNotify event because the font
   size did not change.

It is impossible to prevent this reliably in fvwm, only the
application could do that.  But unfortunately the xterm
Programmers were not aware of this problem and issue a host of
font size changes and window size changes in a single batch
without waiting for a reply from the window manager.  I have
changed the part of the logic in fvwm that surfaced this
particular bug at the cost of similar problems in other
applications.  Maybe I'll rewrite that stuff so that it can
be set individually for each window.

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Tom Alsberg <[email-masked]>
Date: Tue, 7 May 2002 19:26:26 +0300

Hi there.
Comments below:

On Tue, May 07, 2002 at 04:36:13PM +0200, Dominik Vogt wrote:
> > <snip />
> with a lack of functionality in X.

Uhmm... That sounds weird... Both since that problem is new in the
FVWM 2.5 CVS code (didn't exist in FVWM 2.4), and it doesn't happen in
other window managers...

> When an application changes
> has changed, but not to which height and width. 

Uh... Well, I didn't even know that applications notify X that their
font size has changed... I thought only the general (pixel-based, and
geometry) size is reported... But well, the size of the window isn't
exactly the font's size multiplied by the geometry... There can be
other widgets not counted, for example... Take For example XTerm and
Emacs, both with the same font size, both with the same geometry, the
pixel size of the window is different...
I thought that the geometry's meaning is defined by the application,
so the application, given a geometry, decides on the window's size by
itself, and reports that to X...

> So, fvwm looks up that information on its own - but at the time it
> get to it, the size may already have changed again.  For exampe:
> 

Uh... well, but in my example, there is only one font change... so why
does it really matter? The font size changes only once, and while FVWM
is informed on it, there are no further size changes...

> application could do that. 

So why does it only happen in CVS versions of FVWM 2.5? It does not
happen in FVWM 2.4, TWM, CTWM, MWM, Enlightenment, etc... There must
be something in FVWM too...

> But unfortunately the xterm Programmers were not aware of this
> problem and issue a host of  font size changes and window size
> changes in a single batch without waiting for a reply from the
> window manager.

But how does this matter if the size changes only once?

> I have changed the part of the logic in fvwm that surfaced this
> applications.

What do you mean by that?

Isn't it possible to just do it the way FVWM 2.4 did it?

> Maybe I'll rewrite that stuff so that it can be set individually for
> each window.

I didn't yet quite understand why that is needed...

> Dominik ^_^  ^_^

  Thank you,
  -- Tom

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 8 May 2002 10:43:21 +0200

> FVWM 2.5 CVS code (didn't exist in FVWM 2.4), and it doesn't happen in

That's because I cleaned up the code that deals with applications
resizing their windows.  I had to make a choice if font size
changes should be done immediately or upon the last notification.
I chose the latter, and that beoke xterm.

> pixel size of the window is different...

In addition to the font size, applications can define a base size
that is added.  The base size is usually the space needed for
scrollbars, menu bars, tool bars etc.  These are different for
different applications.

> is informed on it, there are no further size changes...

Um, *you* say that there is only one font size change.  This one
change would be enough to get the size right with a properly
working window manager.  But most window managers are totally
broken regarding font size changes (at least I've never seen one
that works fine), so xterm also resizes its window manually, and
then request the same font size change again twice:

 - Start with font size 9x15, 90x150 pixels
 - Xterm requests font size 10x16
 - Xterm requests window size 100x160
 - Xterm requests font size 10x16
 - Xterm requests font size 10x16

There's ample opportunity to screw up the geometry.  Even worse,
you can't even blame the programmers of the individual
applications and/or window managers because the spec dealing with
window resizing is lousy and incomplete, hardly more than a pile
of junk.  It doesn't define the proper way to deal with this
problem.

> be something in FVWM too...

See above.  It doesn't happen with other window managers because
they all ignore font size changes completely, as far as I know.
That xterm feature wouldn't work at all with such window managers
if xterm wouldn't ask for the new geometry explicitly.

Some test that is related you may want to try.  Start an xterm in
the bottom right corner:

  $ xterm -geom -0-0

Then increase the font size.  The window should grow towards the
top left corner of the screen, but with most window managers it
grows to the bottom right, off screen.

And another test that is almost unfair:  Start an xterm and
maximize it.  Then, change the font size.  Some window managers
fail in such a bizarre way that it's almost funny to watch.

> But how does this matter if the size changes only once?

See above.

> Isn't it possible to just do it the way FVWM 2.4 did it?

That's roughly what I wanted to say.  Any solution I can think of
has a problem with certain applications.  I can only choose which
applications are broken.

Now, this problen is un-fixable in fvwm:  Start an xterm and hit
shift-+ and shift-- rapidly (faster than the changes can be
applied).  Wait a few seconds until things have settled down.  The
xterm ends up with a more or less random geometry.

> I didn't yet quite understand why that is needed...

Some windows screw up their geometry if the font size change is
applied immediately, and some break if you wait for the last
change before applying it.

Bye

Dominik ^_^  ^_^