Re: Standardizing ConfigureRequest vs. size_inc hints

[Matthias Clasen <maclas gmx de>]

On Sat, 2002-08-17 at 05:04, Dominik Vogt wrote:
> 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.

Yes. So what ? Its only a hint anyway. Clients which can't cope with
the fact that their size may not satisfy the hints are already broken
wrt to the ICCCM anyway.

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

But to prevent that (getting stuck with an invalid size), wouldn't
it be enough to ensure that the constraints are satisfied when the
opaque resize is finished ? And if you find the constraints violated,
you should probably just resize to the closest valid size, not try
to keep the "cell size".

The size hints were certainly not designed with these complex
width-for-height geometry management scenarios in mind. Ideally,
the wm should ask the client if it accepts the new size before
changing it. Does ResizeRedirect help here ?

Matthias