On Tue, May 07, 2002 at 07:26:26PM +0300, Tom Alsberg wrote:
> Hi there.
> Comments below:
>
> On Tue, May 07, 2002 at 04:36:13PM +0200, Dominik Vogt wrote:
> > 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).
> > > <snip />
> >
> > It's not really a bug in fvwm, but a combination of bugs in xterm
> > 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...
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.
> > 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.
>
> 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...
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.
> 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:
> >
> > - 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.
> >
>
> 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...
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.
> > It is impossible to prevent this reliably in fvwm, only the
> > 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...
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 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?
See above.
> > I have changed the part of the logic in fvwm that surfaced this
> > particular bug at the cost of similar problems in other
> > applications.
>
> What do you mean by that?
>
> 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.
> > 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...
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 ^_^ ^_^
--
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 Wed May 08 2002 - 03:44:10 BST