[PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

[Pekka Paalanen]

On Sun, 18 Mar 2018 14:59:58 -0400
Simon Ser <contact at emersion.fr> wrote:

> On March 16, 2018 1:22 PM, Pekka Paalanen <ppaalanen at gmail.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180319/cc9b88a6/attachment.sig>