xdg-shell: about configure, states and ack_configure

[Olivier Fourdan]

----- Original Message -----
> On Thu, 21 Apr 2016 03:57:52 -0400 (EDT)
> Olivier Fourdan <ofourdan at redhat.com> wrote:
> 
> > Hi all,
> > 
> > Following the discussion around the min/max size addition to
> > xdg-shell v6, I would like to get one point about configure events
> > clarified, if possible.
> > 
> > First, a quick reminder of what the spec currently says:
> > 
> > 1. configure:
> > 
> >     The configure event asks the client to resize its surface or to
> >     change its state.
> > 
> >     The width and height arguments specify a hint to the window
> >     about how its surface should be resized in window geometry
> >     coordinates. See set_window_geometry.
> > 
> > 2. state:
> > 
> >     The surface is maximized. The window geometry specified in the
> >     configure event must be obeyed by the client.
> > 
> >     The surface is fullscreen. The window geometry specified in the
> >     configure event must be obeyed by the client.
> > 
> > 3. ack_configure:
> > 
> >     When a configure event is received, if a client commits the
> >     surface in response to the configure event, then the client
> >     must make an ack_configure request sometime before the commit
> >     request, passing along the serial of the configure event.
> > 
> >    and also:
> > 
> >     The compositor expects that the most recently received
> >     ack_configure request at the time of a commit indicates which
> >     configure event the client is responding to.
> > 
> > So, for example, if the compositor sets a state maximized and a size
> > larger than the client would expect, in theory, the client could
> > ignore the request, not configure its surface and never send an
> > ack_configure for that serial.
> > 
> > At least, that was my understanding and that's why I reckoned the
> > client would always have the final word even if the compositor would
> > not follow the min/max size hints.
> > 
> > Thus my questions:
> > 
> >  - Is my understanding of the spec accurate?
> >  - Is the current wording of the spec clear enough?
> >  - If not, should the spec explicitely state that the client may
> > chose not to ack a configure event?
> >  - And at last, is "not sending an ack" the same as "not acking", ie
> > should we add the notion of "nack_configure"?
> 
> Hi,
> 
> I would think that an app that does not ack the latest configure event
> it has received is ill-behaving. A user will see that misbehaviour and
> get annoyed. However, we cannot make it an error, because sometimes
> apps may just take a while to respond.

Not necessarily.

For the general case, the client is not forced to obey the size from the configure events, only notable exception is when the state is maximized or fullscreen.
And this would occur when the compositor sets that state ignoring the min/max size hints.

> The thing about not acking configures is to allow clients to skip
> configure events and only deal with the latest one when they actually
> get around to handling it. It's a form of event compression.

Sure, I understand that and agree, but the current wording make it sound like it's optional:

    The configure event _asks_ the client to resize its surface or to
    change its state.

and

    When a configure event is received, _if_ a client commits the
    surface in response to the configure event, _then_ the client
    must make an ack_configure request sometime before the commit
    request, passing along the serial of the configure event.

All that makes it sound like it's not mandatory (asks ... if). And thinking about it, there are cases where it should be possible for the client to not obey (because if once it acks, it means that it has committed the surface in response of the configure event, and if it's maximized or fullscreen, the size must be obeyed).

Cheers,
Olivier