Re: Standardizing ConfigureRequest vs. size_inc hints

[Dominik Vogt <dominik vogt gmx de>]

On Mon, Aug 19, 2002 at 03:35:06PM +0200, Matthias Clasen wrote:
> > > 
> > > 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

Ah yes, so the point is that it does not depend on the old size.

[snip]

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

You're right.

[snip]

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

It's at least unclear.  In this case the window manager did not
*chose* to do nothing, so the first case doesn't apply.  Instead,
the window manager may or may not call XConfigureWindow.  Whatever
it does, the application doesn't get a ConfigureNotify (same
without a WM).

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

Exactly.  But I believe the is no automatic CN after a
XConfigureWindow() call that changes nothing (have to check that
again).  This is the case I'm addressing.

Bye

Dominik ^_^  ^_^

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