Re: [PATCH wayland-protocols] Introduce xdg-foreign protocol

2016-07-20 Thread Jonas Ådahl 
On Wed, Jul 20, 2016 at 12:04:04PM -0700, Yong Bakos wrote:
> Hi Jonas,
> 
> > On Jul 13, 2016, at 12:58 AM, Jonas Ådahl  wrote:
> > 
> > xdg-foreign is a protocol meant to enable setting up inter surface
> > relationships across clients. Potential use cases are out-of-process
> > dialogs, such as file dialogs, meant to be used by sandboxed processes
> > that may not have the access it needs to implement such dialogs.
> > 
> > It works by enabling a client to export a surface, creating a handle
> > for the exported surface. The handle, in form of a unique string, may
> > be shared in some way with other clients (for example the provider of
> > the file dialog) which can then import the exported surface.
> > 
> > Signed-off-by: Jonas Ådahl 
> 
> Interesting protocol. Just a wild thought: would surface-exporting be
> something useful in the core Wayland protocol? (Not now, but...)

We abondened that idea years ago. You can search the archives for
wl_foreign_surface. In short, we went with the nested compositing
solution.

> 
> I'll need to re-read and imagine the scenarios, but I feel like there
> is some inconsistency in either the descriptions or the protocol itself.
> Specifically, I thought that the exported surface from client A would
> be displayed by client B as an xdg_toplevel, but then I also see
> set_parent_of, meaning that client B can add subsurfaces to the
> imported surface?

That is not the idea. I'd appreciate some input on how to rephrase
things to make that clear. The idea is that one only affects the
relationship between two xdg surface's, and so far only stacking.

> 
> No need to explain that in length, I think I just need to re-read.
> 
> Some notes inline below.
> 
> 
> > ---
> > 
> > Hi,
> > 
> > This protocol is intended to be used by flatpak's xdg desktop portals, in 
> > order
> > to have a portal dialog (such as a file chooser) to be stacked above (and 
> > maybe
> > as a modal) a parent surface.
> > 
> > A compositor that want to be able to run sandboxed Wayland clients that 
> > need to
> > use portals would need to implement this protocol.
> > 
> > In short, a sandboxed client would "export" its surface and in the process
> > retrieve a server generated handle string, acting as a unique identifier for
> > the exported window. In the flatpak case the client will pass the identifier
> > string via D-Bus to a xdg desktop portal service provider, which will then
> > import it using xdg_importer and create a xdg_imported object that it can be
> > used to modify the stacking relationship.
> > 
> > So far the only supported operation is setting an imported window to be the
> > parent of some surface.
> > 
> > Note that the protocol documentation says "xdg_surface". In the future this
> > would be "xdg_toplevel".
> > 
> > 
> > Jonas
> > 
> > Makefile.am  |   1 +
> > unstable/xdg-foreign/README  |   4 +
> > unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 177 
> > +++
> > 3 files changed, 182 insertions(+)
> > create mode 100644 unstable/xdg-foreign/README
> > create mode 100644 unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index 71d2632..06a1bb2 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -8,6 +8,7 @@ unstable_protocols =
> > \
> > unstable/relative-pointer/relative-pointer-unstable-v1.xml  
> > \
> > unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
> > \
> > unstable/tablet/tablet-unstable-v1.xml  
> > \
> > +   unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> > \
> > $(NULL)
> > 
> > stable_protocols =  
> > \
> > diff --git a/unstable/xdg-foreign/README b/unstable/xdg-foreign/README
> > new file mode 100644
> > index 000..f5bcb83
> > --- /dev/null
> > +++ b/unstable/xdg-foreign/README
> > @@ -0,0 +1,4 @@
> > +xdg foreign protocol
> > +
> > +Maintainers:
> > +Jonas Ådahl 
> > diff --git a/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml 
> > b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> > new file mode 100644
> > index 000..d8a90c3
> > --- /dev/null
> > +++ b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> > @@ -0,0 +1,177 @@
> > +
> > +
> > +
> > +  
> > +Copyright © 2015-2016 Red Hat Inc.
> > +
> > +Permission is hereby granted, free of charge, to any person obtaining a
> > +copy of this software and associated documentation files (the 
> > "Software"),
> > +to deal in the Software without restriction, including without 
> > limitation
> > +the rights to use, copy, modify, merge, publish, distribute, 
> > sublicense,
> > +and/or sell copies of the Software, and to permit persons to whom the
> > +Software is

Re: [PATCH wayland-protocols] Introduce xdg-foreign protocol

2016-07-20 Thread Yong Bakos 
Hi Jonas,

> On Jul 13, 2016, at 12:58 AM, Jonas Ådahl  wrote:
> 
> xdg-foreign is a protocol meant to enable setting up inter surface
> relationships across clients. Potential use cases are out-of-process
> dialogs, such as file dialogs, meant to be used by sandboxed processes
> that may not have the access it needs to implement such dialogs.
> 
> It works by enabling a client to export a surface, creating a handle
> for the exported surface. The handle, in form of a unique string, may
> be shared in some way with other clients (for example the provider of
> the file dialog) which can then import the exported surface.
> 
> Signed-off-by: Jonas Ådahl 

Interesting protocol. Just a wild thought: would surface-exporting be
something useful in the core Wayland protocol? (Not now, but...)

I'll need to re-read and imagine the scenarios, but I feel like there
is some inconsistency in either the descriptions or the protocol itself.
Specifically, I thought that the exported surface from client A would
be displayed by client B as an xdg_toplevel, but then I also see
set_parent_of, meaning that client B can add subsurfaces to the
imported surface?

No need to explain that in length, I think I just need to re-read.

Some notes inline below.


> ---
> 
> Hi,
> 
> This protocol is intended to be used by flatpak's xdg desktop portals, in 
> order
> to have a portal dialog (such as a file chooser) to be stacked above (and 
> maybe
> as a modal) a parent surface.
> 
> A compositor that want to be able to run sandboxed Wayland clients that need 
> to
> use portals would need to implement this protocol.
> 
> In short, a sandboxed client would "export" its surface and in the process
> retrieve a server generated handle string, acting as a unique identifier for
> the exported window. In the flatpak case the client will pass the identifier
> string via D-Bus to a xdg desktop portal service provider, which will then
> import it using xdg_importer and create a xdg_imported object that it can be
> used to modify the stacking relationship.
> 
> So far the only supported operation is setting an imported window to be the
> parent of some surface.
> 
> Note that the protocol documentation says "xdg_surface". In the future this
> would be "xdg_toplevel".
> 
> 
> Jonas
> 
> Makefile.am  |   1 +
> unstable/xdg-foreign/README  |   4 +
> unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 177 +++
> 3 files changed, 182 insertions(+)
> create mode 100644 unstable/xdg-foreign/README
> create mode 100644 unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> 
> diff --git a/Makefile.am b/Makefile.am
> index 71d2632..06a1bb2 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -8,6 +8,7 @@ unstable_protocols =  
> \
>   unstable/relative-pointer/relative-pointer-unstable-v1.xml  
> \
>   unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
> \
>   unstable/tablet/tablet-unstable-v1.xml  
> \
> + unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> \
>   $(NULL)
> 
> stable_protocols =
> \
> diff --git a/unstable/xdg-foreign/README b/unstable/xdg-foreign/README
> new file mode 100644
> index 000..f5bcb83
> --- /dev/null
> +++ b/unstable/xdg-foreign/README
> @@ -0,0 +1,4 @@
> +xdg foreign protocol
> +
> +Maintainers:
> +Jonas Ådahl 
> diff --git a/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml 
> b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> new file mode 100644
> index 000..d8a90c3
> --- /dev/null
> +++ b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> @@ -0,0 +1,177 @@
> +
> +
> +
> +  
> +Copyright © 2015-2016 Red Hat Inc.
> +
> +Permission is hereby granted, free of charge, to any person obtaining a
> +copy of this software and associated documentation files (the 
> "Software"),
> +to deal in the Software without restriction, including without limitation
> +the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +and/or sell copies of the Software, and to permit persons to whom the
> +Software is furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice (including the next
> +paragraph) shall be included in all copies or substantial portions of the
> +Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,

[PATCH wayland-protocols] Introduce xdg-foreign protocol

2016-07-13 Thread Jonas Ådahl 
xdg-foreign is a protocol meant to enable setting up inter surface
relationships across clients. Potential use cases are out-of-process
dialogs, such as file dialogs, meant to be used by sandboxed processes
that may not have the access it needs to implement such dialogs.

It works by enabling a client to export a surface, creating a handle
for the exported surface. The handle, in form of a unique string, may
be shared in some way with other clients (for example the provider of
the file dialog) which can then import the exported surface.

Signed-off-by: Jonas Ådahl 
---

Hi,

This protocol is intended to be used by flatpak's xdg desktop portals, in order
to have a portal dialog (such as a file chooser) to be stacked above (and maybe
as a modal) a parent surface.

A compositor that want to be able to run sandboxed Wayland clients that need to
use portals would need to implement this protocol.

In short, a sandboxed client would "export" its surface and in the process
retrieve a server generated handle string, acting as a unique identifier for
the exported window. In the flatpak case the client will pass the identifier
string via D-Bus to a xdg desktop portal service provider, which will then
import it using xdg_importer and create a xdg_imported object that it can be
used to modify the stacking relationship.

So far the only supported operation is setting an imported window to be the
parent of some surface.

Note that the protocol documentation says "xdg_surface". In the future this
would be "xdg_toplevel".


Jonas

 Makefile.am  |   1 +
 unstable/xdg-foreign/README  |   4 +
 unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 177 +++
 3 files changed, 182 insertions(+)
 create mode 100644 unstable/xdg-foreign/README
 create mode 100644 unstable/xdg-foreign/xdg-foreign-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 71d2632..06a1bb2 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -8,6 +8,7 @@ unstable_protocols =
\
unstable/relative-pointer/relative-pointer-unstable-v1.xml  
\
unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
\
unstable/tablet/tablet-unstable-v1.xml  
\
+   unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
\
$(NULL)
 
 stable_protocols = 
\
diff --git a/unstable/xdg-foreign/README b/unstable/xdg-foreign/README
new file mode 100644
index 000..f5bcb83
--- /dev/null
+++ b/unstable/xdg-foreign/README
@@ -0,0 +1,4 @@
+xdg foreign protocol
+
+Maintainers:
+Jonas Ådahl 
diff --git a/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml 
b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
new file mode 100644
index 000..d8a90c3
--- /dev/null
+++ b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
@@ -0,0 +1,177 @@
+
+
+
+  
+Copyright © 2015-2016 Red Hat Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+  
+
+  
+This protocol specifies a way for making it possible to reference a surface
+of a different client. With such a reference, a client can, by using the
+interfaces provided by this protocol, manipulate the relatioship between 
its
+own surfaces and surface of some other client, for example stack some of 
its
+own surface above the other clients surface.
+
+In order for a client A to get a reference of a surface of client B, client
+B must first export its surface using xdg_exporter.export. Upon doing this,
+client B will receive a handle (a unique string) that it may share with
+client A in some way (for example D-Bus). After client A have received the
+handle from client B, it may use xdg_importer.import to