AW: xemacs trouble maximizing window

[Stephen J. Turnbull]

>>>>> "Glynn" == Glynn Clements <glynn at gclements.plus.com> writes:

    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.

There's probably still an XEmacs bug here.  My prime candidate is that
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.

But it's possible that there is no bug.  The code for the relevant
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
jitter.

While this doesn't seem like the brightest way to do things ex post, I
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.

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.

    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.

Anyway, the Xt model is simply "ask for what you want, and take what
you are given."  As far as I can tell, that's what XEmacs does.


-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.