cross-client surface references

[Pekka Paalanen]

On Thu, 09 Jul 2015 11:37:06 +0200
Alexander Larsson <alexl at redhat.com> wrote:

> On Thu, 2015-07-09 at 02:19 -0700, Jasper St. Pierre wrote:
> > My issue with this is that you're tying two things together. You want
> > access to """a surface""", and you think you can do this by having
> > global cross-client objects and handles and such. I don't see a need
> > for this. We can just add a new protocol that does what we want.
> > 
> 
> I don't understand your disagreement. The protocol you sketch out is
> exactly the same as the one Jonas sketched, only with different names
> (sandboxed_surface instead of xdg_foreign), and it is very much a
> global cross-client object handle.
> 
> I obviously don't want the actual XdgSurface object from the other
> client, that would be insane. I just want a reference/handle/name for
> it in my client so that i can pass it as an argument to
> my_xdg_surface.set_parent()

It makes a huge difference whether you call
xdg_surface.set_parent(xdg_surface *foreign) or
sandboxed_surface.set_as_child(xdg_surface *owned).

I would probably object the whole concept of "xdg_surface *foreign"
existing, because it implies that there are xdg_surfaces, and
xdg_surfaces that are not really xdg_surfaces.

If something is not really what we say it is, why would we call it with
a false name?

Therefore I like Jasper's general idea as it does not use "pretend
objects".

Wayland does not really support "is a" relationship. Object types on
the protocol level are absolute. If an interface is defined to take an
xdg_surface argument, you cannot pass it an xdg_foreign object, even if
it might work on the wire level.

You might work around that by defining another factory for creating
xdg_surface objects for foreign purposes, but that would mean that
xdg_surface interface would never be able to be extended by version
bumps. Multiple factory interfaces for a single object type that have a
different root (global) object in the creation hierarchy cannot work
unless that object type is frozen to version 1 for all eternity. This
has already happened for wl_buffer and wl_callback.


Thanks,
pq