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

[Marco Martin]

ok, i tried to split the patch and send them with git send-email

--
Marco Martin

On Thu, Sep 14, 2017 at 11:54 AM, Jonas Ådahl  wrote:
> On Tue, Sep 12, 2017 at 08:44:39PM +0200, Marco Martin wrote:
>> On Tue, Aug 22, 2017 at 6:07 PM, Marco Martin  wrote:
>> >> You'll need to create an "unstable v2" version, as this is a
>> >> non-backward compatible change. To do that, copy the XML file, changing
>> >
>> > attached a patch that adds the new v2 file, comments adressed
>>
>> ping? do i still need to do something on it?
>
> Thanks for the ping, and sorry about the delay. The change to the
> protocol looks good to me, I only have three things to comment on:
>
> In general, it's a good idea to first copy (and maybe bump the numbers
> as you did), then in a follow up commit make the changes to the
> protocol. That would make it possible to review the actual changes,
> without having to compare manually.
>
> The other thing is that you also need to add the new file to
> Makefile.am, so that it'll be installed properly.
>
> And lastly, the patch submission procedure we use is sending
> patches to the E-mail list directly, not as attachments. You can do this
> for example with git-send-email.
>
>
> Jonas
>
>>
>> --
>> Marco Martin
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Jonas Ådahl]

On Tue, Sep 12, 2017 at 08:44:39PM +0200, Marco Martin wrote:
> On Tue, Aug 22, 2017 at 6:07 PM, Marco Martin  wrote:
> >> You'll need to create an "unstable v2" version, as this is a
> >> non-backward compatible change. To do that, copy the XML file, changing
> >
> > attached a patch that adds the new v2 file, comments adressed
> 
> ping? do i still need to do something on it?

Thanks for the ping, and sorry about the delay. The change to the
protocol looks good to me, I only have three things to comment on:

In general, it's a good idea to first copy (and maybe bump the numbers
as you did), then in a follow up commit make the changes to the
protocol. That would make it possible to review the actual changes,
without having to compare manually.

The other thing is that you also need to add the new file to
Makefile.am, so that it'll be installed properly.

And lastly, the patch submission procedure we use is sending
patches to the E-mail list directly, not as attachments. You can do this
for example with git-send-email.


Jonas

> 
> --
> Marco Martin
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Marco Martin]

On Tue, Aug 22, 2017 at 6:07 PM, Marco Martin  wrote:
>> You'll need to create an "unstable v2" version, as this is a
>> non-backward compatible change. To do that, copy the XML file, changing
>
> attached a patch that adds the new v2 file, comments adressed

ping? do i still need to do something on it?

--
Marco Martin
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Marco Martin]

On Monday 21 August 2017 10:49:55 Jonas Ådahl wrote:
> On Thu, Aug 17, 2017 at 05:05:35PM +0200, Marco Martin wrote:
> > On Thu, Aug 10, 2017 at 3:47 AM, Jonas Ådahl  wrote:
> > > Anyhow, "export_surface" or maybe even "export_toplevel" (as that is the
> > > only thing we allow exporting anyway) seems fine to me. The "import"
> > > request should be renamed in a similar manner as well then.
> > 
> > here attached a patch to rename the calls to export_toplevel and
> > import_toplevel, is that ok?
> 
> You'll need to create an "unstable v2" version, as this is a
> non-backward compatible change. To do that, copy the XML file, changing

attached a patch that adds the new v2 file, comments adressed

-- 
Marco Martin>From 152b44e69c131d470c447f66aa9aadc819d5a1df Mon Sep 17 00:00:00 2001
From: Marco Martin 
Date: Tue, 22 Aug 2017 18:04:25 +0200
Subject: [PATCH] foreignv2: rename export and import calls

as export is a reserved keyword in C++, in order for the
output generated by wayland_scanner to compile correctly
rename export to export_toplevel and import to import_toplevel
this needs a new protocol version as is an incompatible change

Signed-off-by: Marco Martin 
---
 unstable/xdg-foreign/xdg-foreign-unstable-v2.xml | 182 +++
 1 file changed, 182 insertions(+)
 create mode 100644 unstable/xdg-foreign/xdg-foreign-unstable-v2.xml

diff --git a/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml b/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml
new file mode 100644
index 000..8e824c1
--- /dev/null
+++ b/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml
@@ -0,0 +1,182 @@
+
+
+
+  
+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 relationship between
+its own surfaces and the 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 has received the
+handle from client B, it may use xdg_importer.import to create a reference
+to the surface client B just exported. See the corresponding requests for
+details.
+
+A possible use case for this is out-of-process dialogs. For example when a
+sandboxed client without file system access needs the user to select a file
+on the file system, given sandbox environment support, it can export its
+surface, passing the exported surface handle to an unsandboxed process that
+can show a file browser dialog and stack it above the sandboxed client's
+surface.
+
+Warning! The protocol described in this file is experimental and backward
+incompatible changes may be made. Backward compatible changes may be added
+together with the corresponding interface version bump. Backward
+incompatible changes are done by bumping the version number in the protocol
+and interface names and resetting the interface version. Once the protocol
+is to be declared stable, the 'z' prefix and the version number in the
+protocol and interface names are removed and the interface version number is
+reset.
+  
+
+  
+
+  A global interface used for exporting surfaces that can later be imported
+  using xdg_importer.
+
+
+
+  
+	Notify the compositor that the xdg_exporter object will no longer be
+	used.
+  
+
+
+
+  
+	The export_toplevel 

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

[Jonas Ådahl]

On Thu, Aug 17, 2017 at 05:05:35PM +0200, Marco Martin wrote:
> On Thu, Aug 10, 2017 at 3:47 AM, Jonas Ådahl  wrote:
> >
> > Anyhow, "export_surface" or maybe even "export_toplevel" (as that is the 
> > only
> > thing we allow exporting anyway) seems fine to me. The "import" request
> > should be renamed in a similar manner as well then.
> 
> here attached a patch to rename the calls to export_toplevel and
> import_toplevel, is that ok?

You'll need to create an "unstable v2" version, as this is a
non-backward compatible change. To do that, copy the XML file, changing
the v1 to v2 - then make the change. Some comments inline below too:

> 
> --
> Marco Martin

> From 79a050a0a22cb9f04d7679fe2fcd28e797e6957c Mon Sep 17 00:00:00 2001
> From: Marco Martin 
> Date: Thu, 17 Aug 2017 16:58:33 +0200
> Subject: [PATCH] rename export and import calls
> 
> as export is a reserved keyword in C++, in order for the
> output generated by wayland_scanner to compile correctly
> rename export to export_toplevel and import to import_toplevel
> 
> Signed-off-by: Marco Martin 
> ---
>  unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml 
> b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> index 062b090..6d5e1f1 100644
> --- a/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> +++ b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> @@ -69,7 +69,7 @@
>
>  
>  
> -
> +

Would be good to adapt the text below (and in import too) to reflect
this change.


Jonas

>
>   The export request exports the passed surface so that it can later be
>   imported via xdg_importer. When called, a new xdg_exported object will
> @@ -101,7 +101,7 @@
>
>  
>  
> -
> +
>
>   The import request imports a surface from any client given a handle
>   retrieved by exporting said surface using xdg_exporter.export. When
> -- 
> 2.7.4
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Marco Martin]

On Wed, Jul 27, 2016 at 9:54 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.

one question about set_parent_of: what is the cardinality of
parent/child relationship? can an imported surface be parent of more
than one child? a child i suppose can't have more than one parent? is
the server supposed to take care of it? (silently replacing the old
relationships or sending protocol errors?)

--
Marco Martin
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Marco Martin]

On Thu, Aug 10, 2017 at 3:47 AM, Jonas Ådahl  wrote:
>
> Anyhow, "export_surface" or maybe even "export_toplevel" (as that is the only
> thing we allow exporting anyway) seems fine to me. The "import" request
> should be renamed in a similar manner as well then.

here attached a patch to rename the calls to export_toplevel and
import_toplevel, is that ok?

--
Marco Martin
From 79a050a0a22cb9f04d7679fe2fcd28e797e6957c Mon Sep 17 00:00:00 2001
From: Marco Martin 
Date: Thu, 17 Aug 2017 16:58:33 +0200
Subject: [PATCH] rename export and import calls

as export is a reserved keyword in C++, in order for the
output generated by wayland_scanner to compile correctly
rename export to export_toplevel and import to import_toplevel

Signed-off-by: Marco Martin 
---
 unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
index 062b090..6d5e1f1 100644
--- a/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
+++ b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
@@ -69,7 +69,7 @@
   
 
 
-
+
   
 	The export request exports the passed surface so that it can later be
 	imported via xdg_importer. When called, a new xdg_exported object will
@@ -101,7 +101,7 @@
   
 
 
-
+
   
 	The import request imports a surface from any client given a handle
 	retrieved by exporting said surface using xdg_exporter.export. When
-- 
2.7.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Jonas Ådahl]

On Thu, Aug 10, 2017 at 10:44:30AM +0200, Marco Martin wrote:
> On Thu, Aug 10, 2017 at 3:47 AM, Jonas Ådahl  wrote:
> > On Wed, Aug 09, 2017 at 01:42:51PM +0200, Marco Martin wrote:
> >> On Wednesday 27 July 2016 15:54:58 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.
> >>
> >> a quick feedback while trying on implementing it in kde side.
> >> since we use c++, the file generated by wayland-scanner, won't compile due 
> >> to
> >> the request called "export" which is a reserved keyword in c++11.
> >> could the request be renamed to something else, even just a bit more 
> >> redundant
> >> as export_surface which would be safer as compilers are concerned?
> >
> > Ah. Would make sense with a test case for this in wayland-scanner I'd
> > say, so we don't add other things that would make it not compile with a
> > c++ compiler.
> >
> > Anyhow, "export_surface" or maybe even "export_toplevel" (as that is the 
> > only
> > thing we allow exporting anyway) seems fine to me. The "import" request
> > should be renamed in a similar manner as well then.
> >
> 
> yeah, export_toplevel/import_toplevel sounds good.
> if there is a continuous integration somewhere, could be nice just
> make it try compiling the file resulting from wayland-scanner with g++
> -std=c++14 or something like that

There is a very tiny test suite in wayland-protocols. It could be
extended to test build for various variants of C and C++. Currently it
just tests that wayland-scanner doesn't complain.


Jonas

> 
> --
> Marco Martin
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Marco Martin]

On Thu, Aug 10, 2017 at 3:47 AM, Jonas Ådahl  wrote:
> On Wed, Aug 09, 2017 at 01:42:51PM +0200, Marco Martin wrote:
>> On Wednesday 27 July 2016 15:54:58 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.
>>
>> a quick feedback while trying on implementing it in kde side.
>> since we use c++, the file generated by wayland-scanner, won't compile due to
>> the request called "export" which is a reserved keyword in c++11.
>> could the request be renamed to something else, even just a bit more 
>> redundant
>> as export_surface which would be safer as compilers are concerned?
>
> Ah. Would make sense with a test case for this in wayland-scanner I'd
> say, so we don't add other things that would make it not compile with a
> c++ compiler.
>
> Anyhow, "export_surface" or maybe even "export_toplevel" (as that is the only
> thing we allow exporting anyway) seems fine to me. The "import" request
> should be renamed in a similar manner as well then.
>

yeah, export_toplevel/import_toplevel sounds good.
if there is a continuous integration somewhere, could be nice just
make it try compiling the file resulting from wayland-scanner with g++
-std=c++14 or something like that

--
Marco Martin
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Jonas Ådahl]

On Wed, Aug 09, 2017 at 01:42:51PM +0200, Marco Martin wrote:
> On Wednesday 27 July 2016 15:54:58 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.
> 
> a quick feedback while trying on implementing it in kde side.
> since we use c++, the file generated by wayland-scanner, won't compile due to 
> the request called "export" which is a reserved keyword in c++11.
> could the request be renamed to something else, even just a bit more 
> redundant 
> as export_surface which would be safer as compilers are concerned?

Ah. Would make sense with a test case for this in wayland-scanner I'd
say, so we don't add other things that would make it not compile with a
c++ compiler.

Anyhow, "export_surface" or maybe even "export_toplevel" (as that is the only
thing we allow exporting anyway) seems fine to me. The "import" request
should be renamed in a similar manner as well then.


Jonas

> 
> -- 
> Marco Martin
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Marco Martin]

On Wednesday 27 July 2016 15:54:58 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.

a quick feedback while trying on implementing it in kde side.
since we use c++, the file generated by wayland-scanner, won't compile due to 
the request called "export" which is a reserved keyword in c++11.
could the request be renamed to something else, even just a bit more redundant 
as export_surface which would be safer as compilers are concerned?

-- 
Marco Martin
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Jonas Ådahl]

On Sun, Aug 07, 2016 at 08:14:32AM -0500, Derek Foreman wrote:
> On 05/08/16 10:52 AM, Jonas Ådahl wrote:
> > On Fri, Aug 05, 2016 at 07:45:50AM -0500, Derek Foreman wrote:
> >> On 27/07/16 02:54 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.
> >>
> >> Have you considered passing an fd (have the compositor create a pipe)
> >> instead of a string?
> >>
> >> Then the shared token is impossible to guess.
> > 
> > As Carsten wrote in the other E-mail, a client can be lazy and generate
> > a bad string. The client also wouldn't be able to generate a globally
> > unique string, so to import a handle, the importing client would also
> > need to associate the string with some kind of client id.
> 
> Why would clients be generating strings?
> 
> I think maybe I was too terse, I've explained what I'd intended the fd
> to be used for in my other reply.
> 
> I'm fine with the proposal as-is though,  I just though perhaps a method
> in which nobody generated a string at all would be better. :)

Passing a string has the benefit of making it easy to pass in a display
protocol agnostic parent protocol (which is the case for the flatpak
portal; it either passes "x11:" or "wayland:". Maybe it would be possible to still have it pass a string some
how even if the protocol doesn't include that part, but lets explore
that another day.

I landed the patch as is with the RB's given in this thread, and it was
included in the same release as the idle-inhibit protocol.


Jonas

> 
> Thanks,
> Derek
> 
> >>
> >> Even so, this looks workable and not too hard to implement.
> >>
> >> Reviewed-by: Derek Foreman 
> > 
> > Thanks!
> > 
> > 
> > Jonas
> > 
> >>
> >> Thanks,
> >> Derek
> >>> Signed-off-by: Jonas Ådahl 
> >>> ---
> >>>
> >>> Changes since v1:
> >>>
> >>>  - Spelling and grammar fixes
> >>>  - Wording changes (unexport -> revoke)
> >>>  - Fixed the "Warning! .. unstable .." paragraph (was an old version)
> >>>  - Added sandbox client -> unsandboxed file browser dialog example to 
> >>> protocol
> >>>description
> >>>  - Removed left-over note about restriction of importing a handle only 
> >>> once. It
> >>>should be possible to import a handle multiple times, but the protocol 
> >>> text
> >>>had only been updated in one of two places.
> >>>
> >>>
> >>> Jonas
> >>>
> >>>
> >>>
> >>>  Makefile.am  |   1 +
> >>>  unstable/xdg-foreign/README  |   4 +
> >>>  unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 186 
> >>> +++
> >>>  3 files changed, 191 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 9e2a029..35df201 100644
> >>> --- a/Makefile.am
> >>> +++ b/Makefile.am
> >>> @@ -9,6 +9,7 @@ unstable_protocols =  
> >>> \
> >>>   unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
> >>> \
> >>>   unstable/tablet/tablet-unstable-v1.xml  
> >>> \
> >>>   unstable/tablet/tablet-unstable-v2.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..c6f5775
> >>> --- /dev/null
> >>> +++ b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> >>> @@ -0,0 +1,186 @@
> >>> +
> >>> +
> >>> +
> >>> +  
> >>> +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 
> >>> 

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

[Derek Foreman]

On 05/08/16 10:52 AM, Jonas Ådahl wrote:
> On Fri, Aug 05, 2016 at 07:45:50AM -0500, Derek Foreman wrote:
>> On 27/07/16 02:54 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.
>>
>> Have you considered passing an fd (have the compositor create a pipe)
>> instead of a string?
>>
>> Then the shared token is impossible to guess.
> 
> As Carsten wrote in the other E-mail, a client can be lazy and generate
> a bad string. The client also wouldn't be able to generate a globally
> unique string, so to import a handle, the importing client would also
> need to associate the string with some kind of client id.

Why would clients be generating strings?

I think maybe I was too terse, I've explained what I'd intended the fd
to be used for in my other reply.

I'm fine with the proposal as-is though,  I just though perhaps a method
in which nobody generated a string at all would be better. :)

Thanks,
Derek

>>
>> Even so, this looks workable and not too hard to implement.
>>
>> Reviewed-by: Derek Foreman 
> 
> Thanks!
> 
> 
> Jonas
> 
>>
>> Thanks,
>> Derek
>>> Signed-off-by: Jonas Ådahl 
>>> ---
>>>
>>> Changes since v1:
>>>
>>>  - Spelling and grammar fixes
>>>  - Wording changes (unexport -> revoke)
>>>  - Fixed the "Warning! .. unstable .." paragraph (was an old version)
>>>  - Added sandbox client -> unsandboxed file browser dialog example to 
>>> protocol
>>>description
>>>  - Removed left-over note about restriction of importing a handle only 
>>> once. It
>>>should be possible to import a handle multiple times, but the protocol 
>>> text
>>>had only been updated in one of two places.
>>>
>>>
>>> Jonas
>>>
>>>
>>>
>>>  Makefile.am  |   1 +
>>>  unstable/xdg-foreign/README  |   4 +
>>>  unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 186 
>>> +++
>>>  3 files changed, 191 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 9e2a029..35df201 100644
>>> --- a/Makefile.am
>>> +++ b/Makefile.am
>>> @@ -9,6 +9,7 @@ unstable_protocols =
>>> \
>>> unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
>>> \
>>> unstable/tablet/tablet-unstable-v1.xml  
>>> \
>>> unstable/tablet/tablet-unstable-v2.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..c6f5775
>>> --- /dev/null
>>> +++ b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
>>> @@ -0,0 +1,186 @@
>>> +
>>> +
>>> +
>>> +  
>>> +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 

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

[Derek Foreman]

On 05/08/16 09:18 AM, Carsten Haitzler (The Rasterman) wrote:
> On Fri, 5 Aug 2016 07:45:50 -0500 Derek Foreman  said:
> 
>> On 27/07/16 02:54 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.
>>
>> Have you considered passing an fd (have the compositor create a pipe)
>> instead of a string?
>>
>> Then the shared token is impossible to guess.
>>
>> Even so, this looks workable and not too hard to implement.
> 
> are you sure this should just be some client chosen string. this sounds bad in
> that it means if client choose bad strings they compromise their security.

Hi, are you asking me this?  I'm sure it shouldn't be.  :)

My suggestion was to have the compositor create a pipefd, hand the pipe
to the exporter, then the exporter hands the pipe to the importer via
some exogenous method (dbus, sendmsg, whatever), and then the compositor
verifies that the fd is the other end of the pipe from the one it kept
to itself.

> https://git.enlightenment.org/core/efl.git/tree/src/lib/ecore_wayland/session-recovery.xml
> 
> - the compositor will provide a uuid via an event. the idea is the compositor
> picks some big long sha1 or whatever hash string. client supplies this if it
> reconnects after compositor went away unexpectedly (crash/restart/upgrade).
> 
> i think a similar system but uuid's for "naming a surface" would be good. then
> client a can say "hey this dialog is for uuid xyz" as long as the client 
> owning
> xyz can provide the uuid do this other one.
> 
> the point of uuid's is so they CAN survive process restarts too, compositor
> restarts etc. unlike fd's where the last process holding that fd dies  you
> lost the handle.

(The rest of this is more about EFL's session recovery protocols than
xdg-foreign...)

Well, the client is going to have to recreate all of its surfaces on
reconnect, and only the top level surfaces are positioned entirely by
the compositor without app knowledge, so those are really the only ones
that need UUIDs, so they can be accurately repositioned.

I think it might be easier to have the clients re-negotiate the foreign
stuff than to try to have compositor remember any of that over restart.
This also avoids ever having to try to remember any kind of grab state
over a compositor restart.

This is, of course, assuming EFL apps ever need xdg-foreign or non-EFL
apps that do ever speak our session recovery protocol. :)

Thanks,
Derek

>> Reviewed-by: Derek Foreman 
>>
>> Thanks,
>> Derek
>>> Signed-off-by: Jonas Ådahl 
>>> ---
>>>
>>> Changes since v1:
>>>
>>>  - Spelling and grammar fixes
>>>  - Wording changes (unexport -> revoke)
>>>  - Fixed the "Warning! .. unstable .." paragraph (was an old version)
>>>  - Added sandbox client -> unsandboxed file browser dialog example to
>>> protocol description
>>>  - Removed left-over note about restriction of importing a handle only
>>> once. It should be possible to import a handle multiple times, but the
>>> protocol text had only been updated in one of two places.
>>>
>>>
>>> Jonas
>>>
>>>
>>>
>>>  Makefile.am  |   1 +
>>>  unstable/xdg-foreign/README  |   4 +
>>>  unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 186 
>>> +++ 3 files changed, 191 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 9e2a029..35df201 100644
>>> --- a/Makefile.am
>>> +++ b/Makefile.am
>>> @@ -9,6 +9,7 @@ unstable_protocols
>>> =   \
>>> unstable/pointer-constraints/pointer-constraints-unstable-v1.xml\
>>> unstable/tablet/tablet-unstable-v1.xml
>>> \
>>> unstable/tablet/tablet-unstable-v2.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
>>> 

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

[Jonas Ådahl]

On Fri, Aug 05, 2016 at 07:45:50AM -0500, Derek Foreman wrote:
> On 27/07/16 02:54 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.
> 
> Have you considered passing an fd (have the compositor create a pipe)
> instead of a string?
> 
> Then the shared token is impossible to guess.

As Carsten wrote in the other E-mail, a client can be lazy and generate
a bad string. The client also wouldn't be able to generate a globally
unique string, so to import a handle, the importing client would also
need to associate the string with some kind of client id.

> 
> Even so, this looks workable and not too hard to implement.
> 
> Reviewed-by: Derek Foreman 

Thanks!


Jonas

> 
> Thanks,
> Derek
> > Signed-off-by: Jonas Ådahl 
> > ---
> > 
> > Changes since v1:
> > 
> >  - Spelling and grammar fixes
> >  - Wording changes (unexport -> revoke)
> >  - Fixed the "Warning! .. unstable .." paragraph (was an old version)
> >  - Added sandbox client -> unsandboxed file browser dialog example to 
> > protocol
> >description
> >  - Removed left-over note about restriction of importing a handle only 
> > once. It
> >should be possible to import a handle multiple times, but the protocol 
> > text
> >had only been updated in one of two places.
> > 
> > 
> > Jonas
> > 
> > 
> > 
> >  Makefile.am  |   1 +
> >  unstable/xdg-foreign/README  |   4 +
> >  unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 186 
> > +++
> >  3 files changed, 191 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 9e2a029..35df201 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -9,6 +9,7 @@ unstable_protocols =
> > \
> > unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
> > \
> > unstable/tablet/tablet-unstable-v1.xml  
> > \
> > unstable/tablet/tablet-unstable-v2.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..c6f5775
> > --- /dev/null
> > +++ b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> > @@ -0,0 +1,186 @@
> > +
> > +
> > +
> > +  
> > +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 

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

[The Rasterman]

On Fri, 5 Aug 2016 23:18:19 +0900 Carsten Haitzler (The Rasterman)
 said:

> On Fri, 5 Aug 2016 07:45:50 -0500 Derek Foreman  said:
> 
> > On 27/07/16 02:54 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.
> > 
> > Have you considered passing an fd (have the compositor create a pipe)
> > instead of a string?
> > 
> > Then the shared token is impossible to guess.
> > 
> > Even so, this looks workable and not too hard to implement.
> 
> are you sure this should just be some client chosen string. this sounds bad in
> that it means if client choose bad strings they compromise their security.
> 
> https://git.enlightenment.org/core/efl.git/tree/src/lib/ecore_wayland/session-recovery.xml
> 
> - the compositor will provide a uuid via an event. the idea is the compositor
> picks some big long sha1 or whatever hash string. client supplies this if it
> reconnects after compositor went away unexpectedly (crash/restart/upgrade).
> 
> i think a similar system but uuid's for "naming a surface" would be good. then
> client a can say "hey this dialog is for uuid xyz" as long as the client
> owning xyz can provide the uuid do this other one.
> 
> the point of uuid's is so they CAN survive process restarts too, compositor
> restarts etc. unlike fd's where the last process holding that fd dies  you
> lost the handle.

better:

https://git.enlightenment.org/core/efl.git/tree/src/lib/ecore_wl2/session-recovery.c
https://git.enlightenment.org/core/efl.git/tree/src/lib/ecore_wl2/session-recovery.h

and wrapper:

https://git.enlightenment.org/core/efl.git/tree/src/lib/ecore_wl2/ecore_wl2_window.c

> > Reviewed-by: Derek Foreman 
> > 
> > Thanks,
> > Derek
> > > Signed-off-by: Jonas Ådahl 
> > > ---
> > > 
> > > Changes since v1:
> > > 
> > >  - Spelling and grammar fixes
> > >  - Wording changes (unexport -> revoke)
> > >  - Fixed the "Warning! .. unstable .." paragraph (was an old version)
> > >  - Added sandbox client -> unsandboxed file browser dialog example to
> > > protocol description
> > >  - Removed left-over note about restriction of importing a handle only
> > > once. It should be possible to import a handle multiple times, but the
> > > protocol text had only been updated in one of two places.
> > > 
> > > 
> > > Jonas
> > > 
> > > 
> > > 
> > >  Makefile.am  |   1 +
> > >  unstable/xdg-foreign/README  |   4 +
> > >  unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 186 ++
> > > ++ +++ 3 files changed, 191 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 9e2a029..35df201 100644
> > > --- a/Makefile.am
> > > +++ b/Makefile.am
> > > @@ -9,6 +9,7 @@ unstable_protocols
> > > = \
> > > unstable/pointer-constraints/pointer-constraints-unstable-v1.xml  \
> > > unstable/tablet/tablet-unstable-v1.xml
> > > \
> > > unstable/tablet/tablet-unstable-v2.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..c6f5775
> > > --- /dev/null
> > > +++ b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> > > @@ -0,0 +1,186 @@
> > > +
> > > +
> > > +
> > > +  
> > > +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 

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

[The Rasterman]

On Fri, 5 Aug 2016 07:45:50 -0500 Derek Foreman  said:

> On 27/07/16 02:54 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.
> 
> Have you considered passing an fd (have the compositor create a pipe)
> instead of a string?
> 
> Then the shared token is impossible to guess.
> 
> Even so, this looks workable and not too hard to implement.

are you sure this should just be some client chosen string. this sounds bad in
that it means if client choose bad strings they compromise their security.

https://git.enlightenment.org/core/efl.git/tree/src/lib/ecore_wayland/session-recovery.xml

- the compositor will provide a uuid via an event. the idea is the compositor
picks some big long sha1 or whatever hash string. client supplies this if it
reconnects after compositor went away unexpectedly (crash/restart/upgrade).

i think a similar system but uuid's for "naming a surface" would be good. then
client a can say "hey this dialog is for uuid xyz" as long as the client owning
xyz can provide the uuid do this other one.

the point of uuid's is so they CAN survive process restarts too, compositor
restarts etc. unlike fd's where the last process holding that fd dies  you
lost the handle.

> Reviewed-by: Derek Foreman 
> 
> Thanks,
> Derek
> > Signed-off-by: Jonas Ådahl 
> > ---
> > 
> > Changes since v1:
> > 
> >  - Spelling and grammar fixes
> >  - Wording changes (unexport -> revoke)
> >  - Fixed the "Warning! .. unstable .." paragraph (was an old version)
> >  - Added sandbox client -> unsandboxed file browser dialog example to
> > protocol description
> >  - Removed left-over note about restriction of importing a handle only
> > once. It should be possible to import a handle multiple times, but the
> > protocol text had only been updated in one of two places.
> > 
> > 
> > Jonas
> > 
> > 
> > 
> >  Makefile.am  |   1 +
> >  unstable/xdg-foreign/README  |   4 +
> >  unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 186 
> > +++ 3 files changed, 191 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 9e2a029..35df201 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -9,6 +9,7 @@ unstable_protocols
> > =   \
> > unstable/pointer-constraints/pointer-constraints-unstable-v1.xml\
> > unstable/tablet/tablet-unstable-v1.xml
> > \
> > unstable/tablet/tablet-unstable-v2.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..c6f5775
> > --- /dev/null
> > +++ b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> > @@ -0,0 +1,186 @@
> > +
> > +
> > +
> > +  
> > +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 

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

[Derek Foreman]

On 27/07/16 02:54 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.

Have you considered passing an fd (have the compositor create a pipe)
instead of a string?

Then the shared token is impossible to guess.

Even so, this looks workable and not too hard to implement.

Reviewed-by: Derek Foreman 

Thanks,
Derek
> Signed-off-by: Jonas Ådahl 
> ---
> 
> Changes since v1:
> 
>  - Spelling and grammar fixes
>  - Wording changes (unexport -> revoke)
>  - Fixed the "Warning! .. unstable .." paragraph (was an old version)
>  - Added sandbox client -> unsandboxed file browser dialog example to protocol
>description
>  - Removed left-over note about restriction of importing a handle only once. 
> It
>should be possible to import a handle multiple times, but the protocol text
>had only been updated in one of two places.
> 
> 
> Jonas
> 
> 
> 
>  Makefile.am  |   1 +
>  unstable/xdg-foreign/README  |   4 +
>  unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 186 
> +++
>  3 files changed, 191 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 9e2a029..35df201 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -9,6 +9,7 @@ unstable_protocols =  
> \
>   unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
> \
>   unstable/tablet/tablet-unstable-v1.xml  
> \
>   unstable/tablet/tablet-unstable-v2.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..c6f5775
> --- /dev/null
> +++ b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> @@ -0,0 +1,186 @@
> +
> +
> +
> +  
> +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 relationship between
> +its own surfaces and the 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 has received the
> +handle from 

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

[Yong Bakos]

On Jul 27, 2016, at 12:54 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 

Jonas,
Seems clearer now (whether per your changes or by time for me to grok).
A couple minor things noted inline below, and one issue at the very end,
which you could fix up before / after pushing rather than a v3.

I do still think that xdg_imported/exported would be better named
xdg_import/export or xdg_imported_surface/xdg_exported_surface. Just
my humble opinion.

Reviewed-by: Yong Bakos 

yong


> ---
> 
> Changes since v1:
> 
> - Spelling and grammar fixes
> - Wording changes (unexport -> revoke)
> - Fixed the "Warning! .. unstable .." paragraph (was an old version)
> - Added sandbox client -> unsandboxed file browser dialog example to protocol
>   description
> - Removed left-over note about restriction of importing a handle only once. It
>   should be possible to import a handle multiple times, but the protocol text
>   had only been updated in one of two places.
> 
> 
> Jonas
> 
> 
> 
> Makefile.am  |   1 +
> unstable/xdg-foreign/README  |   4 +
> unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 186 +++
> 3 files changed, 191 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 9e2a029..35df201 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -9,6 +9,7 @@ unstable_protocols =  
> \
>   unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
> \
>   unstable/tablet/tablet-unstable-v1.xml  
> \
>   unstable/tablet/tablet-unstable-v2.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..c6f5775
> --- /dev/null
> +++ b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> @@ -0,0 +1,186 @@
> +
> +
> +
> +  
> +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 relationship between
> +its own surfaces and the surface of some other client. For example, stack
> +some of its own surface above the other clients surface.

some of its own surfaces above the other client's surface.


> +
> +In order for a client A to get a reference of a surface of client B, 
> client
> +B must first export its 

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

[Mike Blumenkrantz]

Reviewed-By: Mike Blumenkrantz 

On Wed, Jul 27, 2016 at 3:55 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 
> ---
>
> Changes since v1:
>
>  - Spelling and grammar fixes
>  - Wording changes (unexport -> revoke)
>  - Fixed the "Warning! .. unstable .." paragraph (was an old version)
>  - Added sandbox client -> unsandboxed file browser dialog example to
> protocol
>description
>  - Removed left-over note about restriction of importing a handle only
> once. It
>should be possible to import a handle multiple times, but the protocol
> text
>had only been updated in one of two places.
>
>
> Jonas
>
>
>
>  Makefile.am  |   1 +
>  unstable/xdg-foreign/README  |   4 +
>  unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 186
> +++
>  3 files changed, 191 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 9e2a029..35df201 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -9,6 +9,7 @@ unstable_protocols =
>   \
> unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
>   \
> unstable/tablet/tablet-unstable-v1.xml
>   \
> unstable/tablet/tablet-unstable-v2.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..c6f5775
> --- /dev/null
> +++ b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> @@ -0,0 +1,186 @@
> +
> +
> +
> +  
> +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 relationship
> between
> +its own surfaces and the 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 has received
> the
> +handle from client B, it may use xdg_importer.import to create a
> reference
> +to the surface client B just exported. See the corresponding requests
> for
> +details.
> +
> +A possible use case for this is out-of-process dialogs. For example
> when a
> +sandboxed client without file system access needs the user to select
> 

[PATCH wayland-protocols v2] Introduce xdg-foreign protocol

[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 
---

Changes since v1:

 - Spelling and grammar fixes
 - Wording changes (unexport -> revoke)
 - Fixed the "Warning! .. unstable .." paragraph (was an old version)
 - Added sandbox client -> unsandboxed file browser dialog example to protocol
   description
 - Removed left-over note about restriction of importing a handle only once. It
   should be possible to import a handle multiple times, but the protocol text
   had only been updated in one of two places.


Jonas



 Makefile.am  |   1 +
 unstable/xdg-foreign/README  |   4 +
 unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 186 +++
 3 files changed, 191 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 9e2a029..35df201 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -9,6 +9,7 @@ unstable_protocols =
\
unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
\
unstable/tablet/tablet-unstable-v1.xml  
\
unstable/tablet/tablet-unstable-v2.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..c6f5775
--- /dev/null
+++ b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
@@ -0,0 +1,186 @@
+
+
+
+  
+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 relationship between
+its own surfaces and the 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 has received the
+handle from client B, it may use xdg_importer.import to create a reference
+to the surface client B just exported. See the corresponding requests for
+details.
+
+A possible use case for this is out-of-process dialogs. For example when a
+sandboxed client without file system access needs the user to select a file
+on the file system, given sandbox environment support, it can export its
+surface, passing the exported surface handle to an unsandboxed process that
+can show a file browser dialog and stack it above the