cross-client surface references
spitzak at gmail.com
Thu Jul 9 12:53:55 PDT 2015
On Thu, Jul 9, 2015 at 5:58 AM, Jonas Ådahl <jadahl at gmail.com> wrote:
> Yea, an inverse of xdg_surface.set_parent on xdg_foreign sounds like the
> best option to me too. We can't be too specific though, adding too much
> DE design into the protocol (like making it modal or other things that
> might not apply to non-GNOME(?)).
I would think "this is exactly the same as xdg_surface.set_parent" would be
sufficient, since any "desktop specificity" is already defined by the
existence of the xdg_surface.set_parent api.
This "foreign" idea will work. I can't think of any useful objects that are
not already globals other than surfaces, xyz_surface (where xyz is each
possible shell api), and cursors, therefore my concern that you would be
effectively doubling the number of object types in the Wayland api by
adding a foreign version of every one of them, might not be true.
Not adding too much new terminology
> might be preferable as well. There is no such thing as a "dialog"
> anywhere yet for example; is it different from a xdg_surface with a
> parent, and if so in what ways?
Agree that the compositor should only be interested in whether a surface
has a parent. Whether something is a "dialog" is a nebulous concept that is
not part of the compositor api.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel