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

[Jonas Ådahl]

On Sun, Jun 17, 2018 at 06:22:11PM -0400, Simon Ser wrote:
> 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.

If it'd change its preference out of nowhere (e.g. configuration
change), then I wouldn't count that as a glitch really, and the
transition would be glitch free (the compositor and client always have
the same idea of how each frame is drawn). The thing to avoid so is the
glitch where one or two (or so) have the intermediate unwanted state.

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

The rewording sounds good to me. What about adding some paragraph about
the "race condition" and how to work around it?


Jonas


> 
> Simon