AW: xemacs trouble maximizing window

[Glynn Clements]

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
this.

> 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.

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
settings.

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 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.

That's my suspicion.

> 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.

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
actions.

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[1], so
it clearly notes the resize but doesn't update the hints until an
internally-driven change forces it to notify the WM.

[1] 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 what
> 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 at gclements.plus.com>