Re: AW: xemacs trouble maximizing window
Stephen J. Turnbull wrote:
Glynn> My guess is that the WM makes the window the full size
of
Glynn> the screen, ignoring the gridding constraints, XEmacs
Glynn> recomputes the correct size according to the gridding
Glynn> constraints, and the WM then resizes the window to the new
Glynn> size.
If so, the WMs are broken. The WM should just say no: "you're
maximized, I just set you that way, and that's that---shut up and get
to work." See the ICCCM, and also the Xt shell spec.
The ICCCM doesn't mention the term "maximized". It's really a Windows
concept which has been incorporated into various window managers.
Why this gets into a loop I don't understand. There should be a
flash, then XEmacs will docilely stay maximized.
Re fixing: I guess there must be some protocol for maximizing by now
so that XEmacs can find out that it is in fact "maximized", or we can
use a heuristic of matching the size the WM specifies to the size of
the screen (note that this *will* be heuristic, because XEmacs cannot
know if there will be decorations or what size they are in this state;
I guess we can query the Shell widget for its size, which might be
more accurate.)
Glynn> XEmacs probably shouldn't be specifying an absolute
size.
If the window size is specified in characters and the size of the
characters change, it should. I *want* my window to stay 80 columns
wide when I change from a 10pt font to a 14pt font, or vice versa.
I'm not suggesting that it shouldn't set the base size (PBaseSize) or
the resize increment (PResizeInc), just that it shouldn't set the
overall size (PSize).
OTOH, whether or not the WM will actually honour those settings is a
different matter. Setting an overall size whenever the base size or
resize increment change might be reasonable.
But I suspect that XEmacs probably shouldn't change the overall size
in response to being resized by the WM.
I would assume that any change to the WM_NORMAL_HINTS property /might/
result in the WM resizing the window. If the resize in turn results in
the client changing the WM_NORMAL_HINTS property, that seems like it
could create the risk of a loop.
Glynn> it will be specified at startup to match the geometry
Glynn> resource setting.
Which is in character cells.
Glynn> OTOH, the WM should probably ignore XEmacs' requested size
Glynn> when the user has chosen to maximise the window.
Precisely. The ICCCM doesn't allow the client to resize its toplevel
windows. As far as I can tell, XEmacs does not try to do so.
I think that means that the client shouldn't use XResizeWindow() etc
on top-level shells. I don't think that it's meant to forbid changing
the WM_NORMAL_HINTS hints property to request a resize from the WM.
--
Glynn Clements <glynn(a)gclements.plus.com>