On Monday, April 29, 2019 9:51 AM, Olivier Fourdan <ofour...@redhat.com> wrote: > 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
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. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel