[PATCH wayland-protocols v6] unstable: add xdg-decoration protocol

[Simon Ser]

On June 15, 2018 5:56 PM, Jonas Ådahl <jadahl at gmail.com> wrote:
> Hi,

Hi Jonas,

Thanks for you feedback.

> What about when clients change their "preference" in combination with a
> window state change?
>
> Lets assume the compositor prefers server side, and the current state
> is that the client has set the preferred state to "server_side" as well.
>
> For client driven state change:
>
> client: unset_maximize
> server: configure(server_side, unmaximized)
> client: set_state(client_side)
> server: configure(client_side, unmaximized)
>
> And for the server driven state change:
>
> server: configure(server_side, unmaximized)
> client: set_state(client_side)
> server: configure(client_side, unmaximized)
>
> We'll temporarly have a unwanted configured state after the first
> configures.

That's right. This always happens when the client decides to change its
preference on its own (e.g. when the window contents changes), not just when
it's because of a window state change. The "infinite loop" issue you describe
in case the server always sends configure events is specific to clients
change their preference because of a window state change, though.

> I guess this is work-around:able by requiring the compositor to always
> reply with a configure() event for each (un)set_state() request no
> matter whether any state changed or not (except for the initial state!),
> and require the client to always ignore the configure() event when it
> knows it will change its state preference.
>
> Requiring that is a bit awkward, or what do you think? It'll make an
> extra back-and-forth between the compositor and client a necessity when
> a decoration state preference depends on some other window state. I
> don't have a better alternative in mind though.

I'm okay with requiring the compositor to send configure events, but the second
requirement seems a little weird phrased this way. I don't think we can avoid
the extra roundtrip anyway, because the compositor cannot guess the client's
preferred mode depending on its current state (and we really don't want to make
the compositor able to do that).

So, the client is aware that a set_mode or unset_mode request will always
trigger a configure event. The client is thus responsible for preventing
infinite loops to happen, and this might mean to prevent requests from being
sent if they don't change the client's current preferred mode (in case the
client changes its mode depending on the window state).

In the protocol, we already have:

> After requesting a decoration mode, the compositor will respond by
> emitting a xdg_surface.configure event.

So I think the requirement is already covered by this sentence. We could add
"the compositor will always respond" if we want to play it safe.

However, we also have:

> The compositor can ignore this request.

So we should probably change it to something like:

> The compositor can decide not to use the client's mode and enforce a different
> mode instead.

What do you think?

Simon