AW: xemacs trouble maximizing window

[Glynn Clements]

Stephen J. Turnbull wrote:

>     Glynn> I don't /think/ that Xt rules are relevant here.
> 
> The reason I mention them is that geometry negotiation can go *up*
> from where it starts.  That implies a request to the WM, eventually.
> If that happens in the middle of a WM configuration change, who knows
> what the result might be?

[snip]

>     Glynn> The WM doesn't know what's going on within the client;
>     Glynn> there isn't a right-time/wrong-time for changing property
>     Glynn> settings.
> 
> Oh, are you that sure that the WM is correctly implemented? ;-)
> 
>     Glynn> There's no endpoint where the client can't request a resize
>     Glynn> from the WM until the processing is "complete", but can do
>     Glynn> so after that point.
> 
> Assuming that the WM authors understand that is a bit iffy IMAO. X-P

I don't think it's an issue of understanding anything. There simply
isn't an "endpoint". The WM resizes the window and that's the end of
it.

For the phrase "in the middle of a WM configuration change" to have
any meaning, a WM configuration change has to have a beginning and an
end. It begins when the WM resizes the window, but ends ... when?

If changing the hints is prohibited immediately after the WM has
resized the window, at what point is that prohibition lifted?

It can't be when the client reads the next event; the WM doesn't get
to see any of that happening.

This differs from Xt or Windows, where the system calls an
application-defined callback, and there are restrictions on what can
be done within that callback. There, the endpoint is when the callback
returns.

IOW, I don't think that timing is the issue. The WM is simply trying
to satisfy two contradictory requests: XEmacs' request for a geometry
which results in an integral number of character cells, and the user's
request to make the window fill the desktop.

Obviously, the WM should pick one and be done with it. Preferably the
user's request; XEmacs won't file a bug report if it doesn't get its
way.

>     Glynn> That's how xterm behaves. If you resize the window using
>     Glynn> the WM, the PSize doesn't change. If you select a different
>     Glynn> font size from the Ctrl-RMB menu, it changes the PSize.
> 
> AFAICT, XEmacs _never_ changes the PSize per se.  When you say "PSize"
> do you include the case where one or more of base size, increment, or
> char cell dimensions change?

No:

C-x 5 2:
	WM_NORMAL_HINTS(WM_SIZE_HINTS):
===>		user specified size: 1186 by 998
		program specified minimum size: 94 by 62
		program specified resize increment: 7 by 13
		program specified base size: 24 by 49
		window gravity: NorthWest

Clicking the maximise icon results in:

	WM_NORMAL_HINTS(WM_SIZE_HINTS):
===>		program specified size: 1914 by 1362
		program specified minimum size: 94 by 62
		program specified resize increment: 7 by 13
		program specified base size: 24 by 49
		window gravity: NorthWest

IOW, upon resize, it converts the shell's new absolute size to cells,
then converts that back to pixels and updates the hints accordingly.

This the main difference which I can see between XEmacs and xterm
(which is the obvious test candidate for gridded geometry). xterm only
changes the PSize due to internal changes (e.g. selecting a different
font size); resizing or maximising the window through the WM doesn't
have any effect:

Before:
	WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified size: 564 by 316
		program specified minimum size: 11 by 17
		program specified resize increment: 7 by 13
		program specified base size: 4 by 4

After:
	WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified size: 564 by 316
		program specified minimum size: 11 by 17
		program specified resize increment: 7 by 13
		program specified base size: 4 by 4

I assume that the WM watches for PropertyNotify requests on the
WM_NORMAL_HINTS property, and any change constitutes a new request. If
requests from the application are treated on an equal footing to
users' requests (and they shouldn't be), it will try to satisfy
whoever asked last.

-- 
Glynn Clements <glynn at gclements.plus.com>