cross-client surface references

[Jonas Ådahl]

On Fri, Jul 03, 2015 at 10:37:01AM +0200, Alexander Larsson wrote:
> I understand the ideas behind not allowing one client to access a
> surface from another client. However, there are cases where we really
> want one client to refer to a surface (typically a xdg_surface) from
> another client.
> 
> In particular, I have a need for this in my sandboxing work. Consider a
> setup where a sandboxed application wants to open a file. This will
> happen by the app doing a dbus work to a "portal" which will open a
> file chooser dialog outside the app, and then everything is done will
> return the file contents (not pathname) to the app. In this case we
> want the file chooser dialog to be parented to the proper window. Right
> now there is no way to do this, as the reference to the toplevel is
> client specific. 
> 
> What I would like is for some kind of opt-in request to the compositor
> where I would take an existing xdg_surface reference and create a
> "global" reference that i can serialize (over e.g. dbus) and restore in
> another process and use as an argument for xdg_surface.set_parent().
> Obviously such a reference would be limited in what it could be used
> for, the other app should not be able to call any methods on it like
> changing/reading contents or state.

As an option prior to ending up with taking the nested compositing path,
I had a proposal that sounds similar to what you are talking about:

http://lists.freedesktop.org/archives/wayland-devel/2013-March/008093.html

What it does is allowing mapping a wl_surface with another client
pushes content to. In the linked RFC, the intention was to allow mapping
it only as a subsurface, having the clients have some private method for
doing size synchronization. Doing the same by allowing mapping an
xdg_surface is more complicated I imagine, since one cannot control the
commit timing of the foreign surface if its not a subsurface, but maybe
a wl_foreign_surface could solve that some other way.

Another issue with the linked RFC is that it creates a wl_surface from
some other object than wl_compositor, so that would have to change.

When it was brought up, there were also ideas by using file descriptors
some how as handles, passing around that instead, without having to have
a global "surface ID" namespace of some kind.

Other limitations with this is that such a surface wouldn't be able to
create popup menus (xdg_popup) or sub windows (xdg_surface), so maybe
that is a deal breaker. How to direct input was another unsolved
question.

Maybe what is needed is an xdg_foreign. The Open File dialog provider
client (I don't think it should be part of the server process) would
create a xdg_surface, but before committing it, it'd "export" it similar
to the linked RFC and some how share it with another client via D-Bus.
The client wanting to open a file would then import the xdg_surface by
creating a xdg_foreign from the shared handle. The xdg_foreign would have
functionality that should be provided, for example set_parent but not
configure_ack.


Jonas

> 
> -- 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander Larsson                                            Red Hat, Inc 
>        alexl at redhat.com            alexander.larsson at gmail.com 
> He's an oversexed skateboarding hairdresser with a winning smile and a 
> way with the ladies. She's a virginal impetuous soap star with an 
> incredible destiny. They fight crime! 
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel