[PATCH wayland-protocols] xdg-output: deprecate the xdg_output.done event

[Simon Ser]

On Monday, April 29, 2019 9:51 AM, Olivier Fourdan <ofourdan at redhat.com> wrote:
> Hi,
>
> On Sun, 28 Apr 2019 at 11:19, Simon Ser <contact at emersion.fr> wrote:
> > On Sunday, April 28, 2019 12:04 PM, Olivier Fourdan <ofourdan at redhat.com> wrote:
> > > Humm, I am not sure I like changing xdg-output to rely on another protocol
> > > event, it's looks like a weird mixup to me...
> >
> > As noted below, this is idiomatic in the Wayland protocol. The
> > wl_surface.commit request applies xdg_surface's state.
>
> Sure, yet I reckon it's a bit different, a `commit` is a request and
> not an event

I don't see how this is different. "Request" and "event" are just fancy
names for "protocol message". It's just that one is sent by the client
whereas the other is sent by the server.

> `wl_output.done` is supposed to be sent once all wl_output's
> properties are sent, not other objects' properties such as xdg-output
> own props.

Well the proposal's point is to change this.

> Well, maybe I'm too picky, but xdg-output is a superset of wl_output,
> so I think it's weird to rely on an event from the subset (wl_output)
> to tell when the properties on the superset (xdg-output) are all set.

xdg_surface is a superset of wl_surface too. However it's natural to
rely on wl_surface.commit. I don't understand why it wouldn't be for
xdg_output too.

> IMHO, it would better, semantically, to keep `xdg-output.done` and
> clarify (in xdg-output) that the `xdg-output.done` event is sent once
> all properties on wl_output _and_ xdg-output are set, xdg-output
> being a superset of wl_output. This way we would keep things apart
> but also still guarantee atomicity.

What if we have another protocol that extends wl_output? How can you
atomically send xdg_output state and the other protocol's state?

This solution doesn't scale.

> Besides, that would be easier on the existing clients that would
> (still) expect the `xdg-output.done` event and compositors that
> wouldn't need to emit the event based on the protocol version used by
> the client.

That's a good point. I still think it's worth it to properly fix this
issue.

> > [...]
> > GNOME also doesn't expose all output properties IIRC: the whole list of
> > output modes is not sent.
>
> It does, mutter sends the full list of outputs with their size, scale
> and position and gtk+ relies on it for its GdkMonitor, although there
> are plans to move gtk to use xdg-output as well for its GdkMonitor
> definitions.

The whole list of outputs is sent, however the whole list of output
*modes* isn't. Only the current mode is sent.

I don't think GTK+ should rely on output positions, modes or logical
geometry.