cross-client surface references

[Jonas Ådahl]

On Thu, Jul 09, 2015 at 01:26:09PM +0100, Daniel Stone wrote:
> Hi,
> 
> On 9 July 2015 at 12:51, Alexander Larsson <alexl at redhat.com> wrote:
> > So, you disagree with xdg_surface.set_parent accepting both xdg_surface
> > and xdg_foreign objects?
> 
> It can't. Typing is very strict, and there is no subtyping.
> xdg_surface doesn't extend wl_surface in a traditional (C++/Java)
> style inherited relationship, but rather creates a whole 'nother
> object, and despite their relationship, the two can't be mixed and
> matched. So it has to be a separate request.

Ah right, set_parent takes an xdg_surface, not a wl_surface as the popup
parent does. Then again, an xdg_foreign wouldn't have a wl_surface so
that wouldn't help, nor has it any other common object.

> 
> > One could add xdg_surface.set_foreign_parent() then to make it explicit what is meant.
> 
> Or rather, xdg_foreign.reparent_as_dialog_into(xdg_surface). I like
> the idea of limiting the surface area as much as possible, to not only
> make it explicit as to what is and isn't possible, but also because it
> makes it easier for compositors to implement.

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(?)). 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?


Jonas