Re: Standardizing ConfigureRequest vs. size_inc hints

[Matthias Clasen <maclas gmx de>]

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

I had some time to think about the two use-cases you presented and I believe
that the first one (xterm font change) can be completely solved by 

a) having the client resize after _inc change
b) if the wm wants to act on an _inc change, it should resize in a way which
doesn't depend on anything but the current size hints

The second one (width-for-height geometry management) can't be solved by any
protocol which depends on the client doing something in response to
configure notifies, since it would fail to work for non-opaque resizes, where the
configure notify doesn't happen until
the user interaction is over.

The source of the Qt problem is that the size hints aren't expressive enough
to describe the acceptable sizes of such clients. Thus the fix would be to
increase the expressiveness of the size hints. One way to do so would be to
have _NET_WM_NORMAL_HINTS which would be an array or WM_NORMAL_HINTS structs.
The set of acceptable sizes would be the union of the sets specified by each
WM_NORMAL_HINTS struct. 

> 
> > Does ResizeRedirect help here ?
> 
> What's ResizeRedirect?
> 

ICCCM 4.2.9

Matthias


-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net