Re: Standardizing ConfigureRequest vs. size_inc hints

[Dominik Vogt <dominik vogt gmx de>]

On Mon, Aug 19, 2002 at 12:30:52PM +0200, Matthias Clasen wrote:
>  
> > 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

I don't exactly understand what you mean with "on anything but the
current size hints".  Please explain this a bit more.

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

Yes, I think that would work.  The problem might be that
applications are usually unable to predict their hints when
confronted with a certain geometry because they were written in a
way that just handles the current geometry.

> > > Does ResizeRedirect help here ?

Hm.  Yes, that could solve the problem.  But I'm not happy about
the complexity of the actions involved.  I mean, it's almost
guaranteed that some people don't implement this correctly, making
matters much worse.

--

Maybe a general solution would be to write in the spec:

 - A change in the size_inc or base_size values never entails any
   action by the WM.  If the application requires a size change,
   it MUST trigger a ConfigureRequest.
 - When the window manager receives a ConfigureRequest w/ size or
   position set:
   - If the WM honours the request it re-evaluates the size_inc
     and chooses an appropriate size.
   - If the WM ignores the request for some reason (window is
     maximized or shaded; user has requested a fixed size etc.),
     it at least re-evaluates the size_inc and corrects the
     current window size if necessary.

     Note: The absolute amount of pixels this corrective step
     entails is always smaller than the corresponding size_inc
     calue, i.e. a 5x7 font size can entail a correction of no
     more than +-4 by +-6 pixels.

I will test this approach in fvwm.

--

There are some small inconsistencies w/ COnfigureRequest handling
in the ICCCM that should be clarified:

 1) In order to avoid race conditions with the window manager,
    applications MUST NOT respond to a ConfigureNotify with a
    ConfigureRequest.

    Note:  This rule is not enforced anywhere in the ICCCM.
    Disregarding it is a frequent cause of race conditions.

 2) If an application requests the exaxt size and position for a
    window that it currently has (e.g. requests 100x200 when the
    window geometry is currently is 100x200+5+24), the window
    manager SHOULD respond with a synthetic ConfigureNotify.

    Note:  This slipped through the cracks in the ICCCM.  The
    synthetic event is only mandatory if the application changed
    the position but not the size.  But if it just resized the
    window and the new geometry happens to be the same as the old,
    some applications get confused.  However, this causes a slight
    inconsistency between running under a WM and running on plain
    X.

Bye

Dominik ^_^  ^_^

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