GitLab

This is more of a question rather an issue and would like to get some feedback on the matter.

So, according to the XDG-Shell proto, for set_parent() the following is written:

Setting a null parent for a child window removes any parent-child relationship for the child. Setting a null parent for a window which currently has no parent is a no-op.

Now, in libweston-desktop, the implementation for set_parent() will make sure to call weston_desktop_xdg_toplevel_ensure_added() no matter if the argument to parent is null and there's no check if the current top level surface has any children.

For situations where the client issues a set_parent() for a top level surface which wasn't even added until then, will this be considered as a no-op or my interpretation of the above is faulty?

A consequence of that is that any property set to the top level surface, for instance, if a client does the following:

wl_compositor@4.create_surface(new id wl_surface@38)
xdg_wm_base@18.get_xdg_surface(new id xdg_surface@39, wl_surface@1)
xdg_surface@39.get_toplevel(new id xdg_toplevel@40)
xdg_toplevel@40.set_parent(nil)
xdg_toplevel@40.set_title("title")
wl_surface@38.commit()

will result in the fact that desktop_api.set_parent() will not "see"/gain access to the properties at that time.

Question is, should or shouldn't weston_desktop_xdg_toplevel_ensure_added() be deferred until properties have been added, or alternatively, check if there are any children in case the parent arg being passed is null. I guess that is even easier to check as if the top level surface wasn't even added as it can't have any children obviously.

Notice that changing the order between setting the property and doing set_parent() will change the outcome.