Stephen J. Turnbull wrote:
Glynn> I think that means that the client shouldn't use
Glynn> XResizeWindow() etc on top-level shells.
That's exactly my point. The WM is holding the smoking gun; its
maintainers should stop pointing their fingers at XEmacs and saying
"but you told us to shoot". I'm looking hard for XEmacs prints on the
trigger; I haven't found any yet.
I think it's crazy to say "but the app should know better to ask when
it's been maximized at the user's request". It doesn't know (as you
point out!), and in the X Window System model, it shouldn't need to
know. That's the WM's job.
Hehe; I've just written pretty much the same thing, before having read
There's probably still an XEmacs bug here. My prime candidate is
it's somehow calling XtGeometryRequest from a Resize procedure, which
is explicitly forbidden in the Xt documents. If that propagates up to
the Shell widget, it could result in the symptoms we hear about.
However, in a defensively programmed WM, that should result in CPU
consumption and useless ICCCM protocol, with no visible window jitter.
I don't /think/ that Xt rules are relevant here. Disobeying them might
cause problems for internal geometry management, but ultimately it
shouldn't matter externally. I'm assuming that shell widgets handle
resize requests by changing WM_NORMAL_HINTS rather than calling
XResizeWindow() etc. The WM doesn't know what's going on within the
client; there isn't a right-time/wrong-time for changing property
That kind of thing can matter on Windows, where there is a defined
beginning and end to the processing of a specific event (i.e. between
entry to and return from the WindowProc), and within Xt. But at the
inter-client level, the client gets the ConfigureNotify event and does
whatever it wants with it. There's no endpoint where the client can't
request a resize from the WM until the processing is "complete", but
can do so after that point.
But it's possible that there is no bug. The code for the
widget class methods doesn't seem to explicitly call XtGeometryRequest
that I can find so far. And in fact layout is done in a separate
"thread of control", ie, redisplay. So it's quite possible that
having finished the management of the X window, we return to the
read-eval-redisplay loop. At that point redisplay notices that its
idea of window configuration and the actual are out of sync, and
computes its idea of an optimal configuration, and makes the request
for that "natural size". If the WM grants it, then says "oops, that
window is supposed to be maximized" and remaximizes it, bingo! window
That's my suspicion.
While this doesn't seem like the brightest way to do things ex
don't think we can call it an actual bug in XEmacs. Anyway, if that
hypothesis is correct, changing it will be pretty hard, I think.
I suspect it depends upon whether the code which sets the hints can
figure out why it's setting them.
If you can distinguish the case where the parameters have changed
because of a WM-driven resize from the case where they have been
changed internally, you can avoid changing the hints in reponse to WM
That's how xterm behaves. If you resize the window using the WM, the
PSize doesn't change. If you select a different font size from the
Ctrl-RMB menu, it changes the PSize.
If you do both in that order, the change to the font size retains the
updated character-cell geometry following the WM-driven resize, so
it clearly notes the resize but doesn't update the hints until an
internally-driven change forces it to notify the WM.
 Except, using Cygwin's X server in rootless mode with the built-in
WM, if the window is maximised, enlarging the font won't make the
window any larger (Windows doesn't allow windows to be larger than the
desktop), but will reduce the number of character cells instead.
Clicking the restore button restores the window to its previous
overall size (now with fewer cells due to the enlarged font).
Am I missing something? N.B. The point is not to make excuses for
XEmacs, it's to get the symptoms relieved. I think it should be
relatively easy for WMs to do so; my experience so far is that it's
quite hard for XEmacs.
If the WM implements the concept of "maximised" windows, it should
probably ignore the WM_NORMAL_HINTS property for such windows.
Glynn> I would assume that any change to the WM_NORMAL_HINTS
Glynn> property /might/ result in the WM resizing the window. If
Glynn> the resize in turn results in the client changing the
Glynn> WM_NORMAL_HINTS property, that seems like it could create
Glynn> the risk of a loop.
True. And indeed, I believe that's what happened before the "Take
XtGeometryNo for an answer" patch. However, in recent XEmacsen, as
far as I know once they're told "no", they adjust their internal
configuration to that given from outside, and the loop should stop.
The immediate cause of the symptom is that the WM isn't saying "no".
(Unless XEmacs is calling XConfigureWindow on the toplevel Shell's
Window. But I don't think it does.)
Glynn> But I suspect that XEmacs probably shouldn't change the
Glynn> overall size in response to being resized by the WM.
How does it know? Ultimately, *all* resizes are done by the WM.
I mean that it shouldn't change the hints when a resize occurs. It
should change them if internal changes (changes to the font size,
addition or removal of scrollbars, toolbars etc) require a new size.
Without having looked at the code, I would suspect that the issue is
that any change to size-related parameters results in the hints being
updated, regardless of /why/ the parameters changed.
E.g. set-frame-size updates the stored frame size, which causes the
hints to be changed. WM-driven resize updates the stored frame size,
which causes the hints to be changed. The former should result in the
hints being changed, the latter shouldn't. The WM has just told you
what size you're getting; requesting a specific size /in response/
seems likely to be the cause of the troubles.
Anyway, the Xt model is simply "ask for what you want, and take
you are given." As far as I can tell, that's what XEmacs does.
At the client<->WM level, it seems that it's the other way around,
i.e. every time it's given something, it replies with what it would
have rather had instead.
Glynn Clements <glynn(a)gclements.plus.com>