xdg-shell: about configure, states and ack_configure

[Pekka Paalanen]

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.

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.

Adding Jasper to CC.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160421/1d21c9ef/attachment.sig>