AW: xemacs trouble maximizing window

[Glynn Clements]

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 at gclements.plus.com>