Re: AW: xemacs trouble maximizing window

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.