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 > [email protected] [email protected] > 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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
