Re: Standardizing ConfigureRequest vs. size_inc hints

[Dominik Vogt <dominik vogt gmx de>]

On Sat, Aug 17, 2002 at 01:48:26AM +0200, Matthias Clasen wrote:
> On Thu, 2002-08-08 at 23:18, Dominik Vogt wrote:
> 
> > 
> > Let's assume we have a 100x100 client window with width_inc =
> > height_inc = 10.  Consider this scenario.
> > 
> >  1) Window changes the ..._inc to 5.
> >     [WM should resize window to 50x50]
> >  2) Window resizes its window to 100x100
> >     [New required size: 100x100]
> >  3) Window changes the ..._inc to 20.
> >     [New requiredd size: 400x400]
> >
> 
> Dominik, I think the root of the problem is your assumption that the
> wm should react to _inc changes by resizing the window. I can't find
> any sentence in the ICCCM supporting this.

> The ICCCM is very clear
> that clients should use a ConfigureRequest for changing the window size.
> Thus the client in your scenario above is doing the right thing in step
> 2 in resizing the window itself to match the changed _inc. It would be
> broken for the client to assume that changing the _inc is enough to
> request a new window size.

The WM is in no way obliged to grant the values from a
ConfigureRequest.  In fact, many window managers chose to ignore
them while a window is maximized.  So, if they ignore the ..._inc
values too, the window size may not be a multiple of the ..._inc
anymore.

Furthermore, applications are implicitly relying on the window
manager honouring the base size and ..._inc immediately.  For
example, take a Qt application with a menu bar.  When the window
is resized opaque, Qt resizes its contents.  When the window gets
too small, the menu bar is broken into several lines, thus
altering the base_height and height_inc.  If the window manager
does not honour these hints immediately, the window gets stuck
with a geometry not matching the specified hints.  (Not that I
could yet be bothered to add the code handling WM_NORMAL_HINT
changes during a resize operation).

> Do you know any clients doing this ? 

See above.  Qt relies on that behavoiur.  I'm not saying that Qt
is doing the right thing, though.

> The example you cite, xterm, *does* resize the window after changing
> the property. 

Actually, xterm is a bad example because it screws up its position
with the ConfigureRequest.  Try "xterm -geom -0-0" and press
Ctrl-Shift-KP_Plus on the xterm window.  Xterm overrides its
window gravity and grows towards the southeast corner (i.e. off
screen).

> If we need to add anything about this to the EWMH, it should just be
> a clarification that applications are responsible for requesting a
> window size meeting the constraints of the WM_NORMAL_HINTS 
> both a) at initial mapping time
> and b) when they change the WM_NORMAL_HINTS later.
> Window Managers should not react to WM_NORMAL_HINTS changes by changing
> the size of the window, since that leads to race conditions.

Sure, that's all fine.  But it's not going to help anybody unless
applications either

 a) have a way to enforce consistency

or

 b) advertise compliance to that rule in some way

Simply assuming that all applications in the world start honouring
this rule just because it's written in the EWMH spec won't help.
Personally I prefer (a) because only a few applications would have
to be modified, but I believe on the long run we won't get around
(b) anyway.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, dominik vogt gmx de
Reply-To: dominik vogt gmx de