Hi, On Sun, 28 Apr 2019 at 11:19, Simon Ser <cont...@emersion.fr> wrote: > On Sunday, April 28, 2019 12:04 PM, Olivier Fourdan <ofour...@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, `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, 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 guarantee atomicity. 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. https://gitlab.gnome.org/GNOME/gtk/issues/1828 https://gitlab.gnome.org/GNOME/gtk/merge_requests/750 https://gitlab.gnome.org/GNOME/gtk/merge_requests/751 Cheers, Olivier
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel