[PATCH wayland-protocols] xdg-output: deprecate the xdg_output.done event
ofourdan at redhat.com
Mon Apr 29 06:51:03 UTC 2019
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>
> > Humm, I am not sure I like changing xdg-output to rely on another
> > 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, `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
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.
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
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.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel