[PATCH] xdg-foreign-v2: Fix various documentation issues from the API change

[Jonas Ådahl]

It stilled referred to the removed requests, so change those places to
refer to the renamed ones.

While at it, also change documentation to refer directly to
xdg_toplevel, as that has now been introduced.

Signed-off-by: Jonas Ådahl <jadahl at gmail.com>
---

Hi,

On Tue, Sep 26, 2017 at 03:06:05PM +0200, Marco Martin wrote:
> ping?
> 

The API change looks good to me, but the documentation was left
unchanged, thus incorrect. I fixed it in this patch. Please take a look.

Locally I did some minor commit message changes to your patches. For
example I changed the commit message to say 'xdg-foreign' not just
'foreign', as well as some minor similar cosmetic issues.


Jonas




 unstable/xdg-foreign/xdg-foreign-unstable-v2.xml | 30 ++++++++++++------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml b/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml
index 8e824c1..bf46fa8 100644
--- a/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml
+++ b/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml
@@ -32,12 +32,12 @@
     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.
+    B must first export its surface using xdg_exporter.export_toplevel. 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_toplevel
+    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
@@ -77,8 +77,8 @@
 	corresponding interface and event for details.
 
 	A surface may be exported multiple times, and each exported handle may
-	be used to create a xdg_imported multiple times. Only xdg_surface
-	surfaces may be exported.
+	be used to create a xdg_imported multiple times. Only xdg_toplevel
+	equivalent surfaces may be exported.
       </description>
       <arg name="id" type="new_id" interface="zxdg_exported_v2"
 	   summary="the new xdg_exported object"/>
@@ -104,8 +104,8 @@
     <request name="import_toplevel">
       <description summary="import a toplevel surface">
 	The import_toplevel request imports a surface from any client given a handle
-	retrieved by exporting said surface using xdg_exporter.export. When
-	called, a new xdg_imported object will be created. This new object
+	retrieved by exporting said surface using xdg_exporter.export_toplevel.
+	When called, a new xdg_imported object will be created. This new object
 	represents the imported surface, and the importing client can
 	manipulate its relationship using it. See xdg_imported for details.
       </description>
@@ -136,8 +136,8 @@
       <description summary="the exported surface handle">
 	The handle event contains the unique handle of this exported surface
 	reference. It may be shared with any client, which then can use it to
-	import the surface by calling xdg_importer.import. A handle may be
-	used to import the surface multiple times.
+	import the surface by calling xdg_importer.import_toplevel. A handle
+	may be used to import the surface multiple times.
       </description>
       <arg name="handle" type="string" summary="the exported surface handle"/>
     </event>
@@ -161,9 +161,9 @@
     <request name="set_parent_of">
       <description summary="set as the parent of some surface">
 	Set the imported surface as the parent of some surface of the client.
-	The passed surface must be a toplevel xdg_surface. Calling this function
-	sets up a surface to surface relation with the same stacking and positioning
-	semantics as xdg_surface.set_parent.
+	The passed surface must be a xdg_toplevel equivalent. Calling this
+	function sets up a surface to surface relation with the same stacking
+	and positioning semantics as xdg_toplevel.set_parent.
       </description>
       <arg name="surface" type="object" interface="wl_surface"
 	   summary="the child surface"/>
-- 
2.13.5