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

From: Dominik Vogt <fvwm_at_fvwm.org>
Date: Tue, 7 May 2002 16:36:13 +0200

On Tue, May 07, 2002 at 04:53:59PM +0300, Tom Alsberg wrote:
> 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.

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: d.vogt_at_lifebits.de
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 majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Tue May 07 2002 - 10:48:29 BST

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:37:53 BST