Re: AW: xemacs trouble maximizing window
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(a)gclements.plus.com>