Re: Standardizing ConfigureRequest vs. size_inc hints

[Dominik Vogt <dominik vogt gmx de>]

On Sun, Aug 18, 2002 at 10:47:10AM +0200, Matthias Clasen wrote:
> 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 ?

So it looks very ugly and confuses the user.  Ideally, I expect
from a good spec that it at least allows user friendly behaviour
instead of implicitly preventing it.

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

Well, that's the attitude "as long as it isn't my fault, I don't
care a bit about the problem".  There *is* something between
disregarding hints completely and obeying the app hints all the
time.

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

In terms of keeping the geometry valid yes, but not in terms of
being user friendly.  When I have just resized the window
manually, I expect, no, *demand*, that the window is not resized
to some other size immediately afterwards.

Anyway, the suggested solution suffers exactly from the problem I
described initially.  There is a change of the _inc waiting on the
queue and I have to read it although a ConfigureReuquest and
another _inc change may be pending.  For example:

 1) Opaque resizing started with size 200x200, inc 10x10.
 2) User resizes to 100x100 (valid).
 3) Menu bar doesn't fit anymore, app sets _inc to 10x7.
 4) Opaque resize ends.
 5) Before WM has empied the queue, app changes the _inc to 10x9.
 6) WM reads the _inc and limits the window to 100x99 instead of
    100x98.

That doesn't look too bad, but there are pathological cases where
the difference is much more than a pixel.

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

Agreed.

> Does ResizeRedirect help here ?

What's ResizeRedirect?

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: dominik vogt schlund de, phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe