On Sun, 18 Mar 2018 14:59:58 -0400 Simon Ser <[email protected]> wrote:
> On March 16, 2018 1:22 PM, Pekka Paalanen <[email protected]> wrote: > > > > I'm missing a comment that describes what happens if the xdg_toplevel is > > > > destroyed. There is some object dependency here that needs to be > > > > stated. Do > > > > we need an event here? Or are we assuming that clients are smart enough > > > > to > > > > keep track of destroy events. Either way - needs to be explicitly > > > > stated. > > > > > > What about requiring clients to destroy the zxdg_toplevel_decoration_v1 > > > before > > > the xdg_toplevel? > > > > Hi, > > > > you can, but then you need an error code for clients that get it wrong. > > > > A common convention is to instead say that zxdg_toplevel_decoration_v1 > > becomes "inert" when the associated xdg_toplevel is destroyed. It means > > the object will not send any events, and all requests except destroy > > will be ignored. This approach is often used with racy cases where > > requiring a single order of actions is not possible, and it comes with > > the disadvantage of needing to define what happens if you pass an inert > > object of this type as an argument in some other interface, or if the > > inert object had requests that create more objects. > > Thanks for the explanation! > > > Both ways are possible. You may want to check how xdg_toplevel deals > > with xdg_surface destruction and how xdg_surface deals with wl_surface > > destruction. Maybe consistency would be the best plan? > > The protocol states that: "An xdg_surface must only be destroyed after its > role > object has been destroyed". But it doesn't define any error type for protocol > violations. I didn't find anything about the relationship between xdg_surface > and xdg_surface. > > So I'm not sure what to do to be consistent with xdg-shell. The options are: > - Become inert > - Send an error on the decoration object > - Automatically destroying the decoration when the toplevel is destroyed? > > I'll just go with becoming inert for now. Let me know what you think. Hi, I'd just like to point out that the third option to automatically destroy the object is not a good option. If a client first destroys xdg_toplevel and that causes the server to internally destroy the decoration object, then the client will either cause a protocol error with destroying the decoration object (you have protocol for destroy request, and the request will refer to an object that does not exist in the server anymore), or the decoration object needs to have two kinds of destroy functions: one that sends destroy request (I assume there are use cases which do want it) and another that does not, plus the client needs to be careful to use the right one. So to me that seems like the worst option. It's always dangerous for a server to automatically destroy a protocol object, if the object interface has any requests defined. It would need very careful design and use to avoid protocol error inducing races or conditions, so I would advice against it. A destroy request is a request. Where we often have the server automatically destroy an object are interfaces which essentially act as a "return value" delivery, and therefore do not have requests defined. These objects must also never be used as arguments in any requests, or you fall into the can of worms again. I forget what the decoration interface spec says, but if you have a defined consequence from destroying the protocol object, e.g. while the window is still mapped, you need to consider if that may cause a user visible glitch. You cannot assume that sequential requests are handled together, it is possible the compositor can go do something else between *any* two requests. But because usually compositors don't and clients flush out requests in bursts, it is very unlikely to see the glitch problems in normal testing. You would need to use a protocol debugger that added an explicit flush and delay between every single request and event. I hope this helps you decide on a better design. Thanks, pq
pgpwTFWXcL8pK.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
