Re: Standardizing ConfigureRequest vs. size_inc hints

["Matthias Clasen" <Matthias Clasen poet de>]

> > 
> > 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 fvwm behaviour you described was to resize the client in such a way 
that
the "cell size" stays the same. "cell size" is a derived property that 
depends
on 
a) the size of the window
b) the previous size hints

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

Probably. But I don't see any alternatives. 


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

I'm not so sure, since this also fails for non-opaque removes, since the 
client
is not resized until the interaction is over, so there is nothing to 
redirect 
to.

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

Sounds reasonable.

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

I think 4.2.4 comes pretty close: 

  The response of the client to being resized should be to accept the size 
it
  has been given and to do its best with it. Clients must not respond to 
being 
  resized by attempting to resize themselves to a better size. If the size 
is 
  impossible to work with, clients are free to request to change to the 
Iconic 
  state. 

But it can't hurt to clarify this again.

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

Doesn't 4.1.5 already demand this ?

  If the window manager decides to respond to a ConfigureRequest request 
by:

  * Not changing the size, location, border width, or stacking order of 
the 
    window at all.

  A client will receive a synthetic ConfigureNotify event. [...] The 
client 
  will not receive a real ConfigureNotify event because no change has 
actually 
  taken place. 

Sound to me as if the ICCCM authors intended to make sure that the client
always gets a ConfigureNotify in response to its request, in order to 
avoid
the inconsistency to the WM-less case.

Matthias