Signed-off-by: Bryce Harrington <b.harring...@samsung.com>
---
 protocol/desktop-shell.xml |   36 +++++-----
 protocol/xdg-shell.xml     |  157 ++++++++++++++++++++++----------------------
 2 files changed, 97 insertions(+), 96 deletions(-)

diff --git a/protocol/desktop-shell.xml b/protocol/desktop-shell.xml
index 7b34213..15c898c 100644
--- a/protocol/desktop-shell.xml
+++ b/protocol/desktop-shell.xml
@@ -2,9 +2,9 @@
 
   <interface name="desktop_shell" version="2">
     <description summary="create desktop widgets and helpers">
-      Traditional user interfaces can rely on this interface to define the
-      foundations of typical desktops. Currently it's possible to set up
-      background, panels and locking surfaces.
+      Traditional user interfaces can rely on this interface to define
+      the foundations of typical desktops. Currently it's possible to
+      set up background, panels and locking surfaces.
     </description>
 
     <request name="set_background">
@@ -27,18 +27,18 @@
       <description summary="set grab surface">
        The surface set by this request will receive a fake
        pointer.enter event during grabs at position 0, 0 and is
-       expected to set an appropriate cursor image as described by
-       the grab_cursor event sent just before the enter event.
+       expected to set an appropriate cursor image as described by the
+       grab_cursor event sent just before the enter event.
       </description>
       <arg name="surface" type="object" interface="wl_surface"/>
     </request>
 
     <request name="desktop_ready" since="2">
       <description summary="desktop is ready to be shown">
-       Tell the server that enough desktop elements have been drawn
-       to make the desktop look ready for use. During start-up for instance, 
the
-       server can wait for this request with a black screen before
-       starting to fade-in the desktop. If the client
+       Tell the server that enough desktop elements have been drawn to
+       make the desktop look ready for use. During start-up for
+       instance, the server can wait for this request with a black
+       screen before starting to fade-in the desktop. If the client
        parts of a desktop take a long time to initialize, we avoid
        showing temporary garbage.
       </description>
@@ -55,18 +55,18 @@
 
     <event name="prepare_lock_surface">
       <description summary="tell the client to create, set the lock surface">
-       Tell the shell we want it to create and set the lock surface (i.e.
-       a GUI asking the user to unlock the screen.) The lock surface is
-       announced with 'set_lock_surface'. Whether or not the shell actually
-       implements locking, it MUST send 'unlock' request to let the normal
-        desktop resume.
+       Tell the shell we want it to create and set the lock surface
+       (i.e.  a GUI asking the user to unlock the screen.) The lock
+       surface is announced with 'set_lock_surface'. Whether or not the
+       shell actually implements locking, it MUST send 'unlock' request
+       to let the normal desktop resume.
       </description>
     </event>
 
     <event name="grab_cursor">
       <description summary="tell client what cursor to show during a grab">
-       This event will be sent immediately before a fake enter event on the
-       grab surface.
+       This event will be sent immediately before a fake enter event on
+       the grab surface.
       </description>
       <arg name="cursor" type="uint"/>
     </event>
@@ -100,8 +100,8 @@
 
     <request name="set_surface">
       <description summary="set the surface type as a screensaver">
-       A screensaver surface is normally hidden, and only visible after an
-        idle timeout.
+       A screensaver surface is normally hidden, and only visible after
+       an idle timeout.
       </description>
 
       <arg name="surface" type="object" interface="wl_surface"/>
diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml
index a29a5f1..985c1b6 100644
--- a/protocol/xdg-shell.xml
+++ b/protocol/xdg-shell.xml
@@ -92,15 +92,15 @@
       An interface that may be implemented by a wl_surface, for
       implementations that provide a desktop-style user interface.
 
-      This provides requests to treat surfaces like windows, allowing 
+      This provides requests to treat surfaces like windows, allowing
       properties like maximized, fullscreen, minimized to be set.  It
-      also allows windows to be moved and resized, and to
-      associate metadata like title and app id with them.
+      also allows windows to be moved and resized, and to associate
+      metadata like title and app id with them.
 
-      On the server side the object is automatically destroyed when
-      the related wl_surface is destroyed.  On client side,
-      xdg_surface.destroy() must be called before destroying
-      the wl_surface object.
+      On the server side the object is automatically destroyed when the
+      related wl_surface is destroyed. On client side,
+      xdg_surface.destroy() must be called before destroying the
+      wl_surface object.
     </description>
 
     <request name="destroy" type="destructor">
@@ -152,8 +152,8 @@
 
     <request name="pong">
       <description summary="respond to a ping event">
-       A client must respond to a ping event with a pong request or
-       the display server may deem the client unresponsive.
+       A client must respond to a ping event with a pong request or the
+       display server may deem the client unresponsive.
       </description>
       <arg name="serial" type="uint" summary="serial of the ping event"/>
     </request>
@@ -180,10 +180,10 @@
 
     <enum name="resize_edge">
       <description summary="edge values for resizing">
-       These values are used to indicate which edge of a surface
-       is being dragged in a resize operation. The server may
-       use this information to adapt its behavior, e.g. choose
-       an appropriate cursor image.
+       These values are used to indicate which edge of a surface is
+       being dragged in a resize operation. The server may use this
+       information to adapt its behavior, e.g. choose an appropriate
+       cursor image.
       </description>
       <entry name="none" value="0"/>
       <entry name="top" value="1"/>
@@ -217,14 +217,14 @@
        ignore it if it doesn't resize, or even pick a smaller size (to
        satisfy aspect ratio or resize in steps of NxM pixels).
 
-       The edges parameter provides a hint about how the surface
-       was resized. The client may use this information to decide
-       how to adjust its content to the new size (e.g. a scrolling
-       area might adjust its content position to leave the viewable
-       content unmoved). Valid edge values are from resize_edge enum.
+       The edges parameter provides a hint about how the surface was
+       resized. The client may use this information to decide how to
+       adjust its content to the new size (e.g. a scrolling area might
+       adjust its content position to leave the viewable content
+       unmoved). Valid edge values are from resize_edge enum.
 
-       The client is free to dismiss all but the last configure
-       event it received.
+       The client is free to dismiss all but the last configure event
+       it received.
 
        The width and height parameters specify the size of the window
        in surface local coordinates.
@@ -237,31 +237,32 @@
 
     <request name="set_output">
       <description summary="set the default output used by this surface">
-       Set the default output used by this surface when it is first mapped.
+       Set the default output used by this surface when it is first
+       mapped.
 
-       If this value is NULL (default), it's up to the compositor to choose
-       which output will be used to map this surface.
+       If this value is NULL (default), it's up to the compositor to
+       choose which output will be used to map this surface.
 
-       When fullscreen or maximized state are set on this surface, and it
-       wasn't mapped yet, the output set with this method will be used.
-       Otherwise, the output where the surface is currently mapped will be
-       used.
+       When fullscreen or maximized state are set on this surface, and
+       it wasn't mapped yet, the output set with this method will be
+       used.  Otherwise, the output where the surface is currently
+       mapped will be used.
       </description>
       <arg name="output" type="object" interface="wl_output" 
allow-null="true"/>
     </request>
 
     <event name="request_set_fullscreen">
       <description summary="server requests that the client set fullscreen">
-       Event sent by the compositor to request the client 
-       go to a fullscreen state. It's the client's responsibility to call 
set_fullscreen
-       and actually trigger the fullscreen state.
+       Event sent by the compositor to request the client go to a
+       fullscreen state. It's the client's responsibility to call
+       set_fullscreen and actually trigger the fullscreen state.
       </description>
     </event>
 
     <event name="request_unset_fullscreen">
       <description summary="server requests that the client unset fullscreen">
-       Event sent by the compositor to request the client
-       leave the fullscreen state. It's the client's responsibility to call
+       Event sent by the compositor to request the client leave the
+       fullscreen state. It's the client's responsibility to call
        unset_fullscreen and actually leave the fullscreen state.
       </description>
     </event>
@@ -273,20 +274,20 @@
        After this request, the compositor will send a configure event
        with the new output size.
 
-       This request informs the compositor that the next attached buffer
-       committed will be in a fullscreen state. The buffer size should be the
-       same as specified by the configure event, otherwise the client
-       may be forced to leave an area empty.
+       This request informs the compositor that the next attached
+       buffer committed will be in a fullscreen state. The buffer size
+       should be the same as specified by the configure event,
+       otherwise the client may be forced to leave an area empty.
 
-       In other words: the next attached buffer after set_maximized is the new
-       maximized buffer. And the surface will be positioned at the maximized
-       position on commit.
+       In other words: the next attached buffer after set_maximized is
+       the new maximized buffer. And the surface will be positioned at
+       the maximized position on commit.
 
-       A simple way to synchronize and wait for the correct configure event is
-       to use a wl_display.sync request right after the set_fullscreen
-       request. When the sync callback returns, the last configure event
-       received just before it will be the correct one, and should contain the
-       right size for the surface to maximize.
+       A simple way to synchronize and wait for the correct configure
+       event is to use a wl_display.sync request right after the
+       set_fullscreen request. When the sync callback returns, the last
+       configure event received just before it will be the correct one,
+       and should contain the right size for the surface to maximize.
 
        Setting one state won't unset another state. Use
        xdg_surface.unset_fullscreen for unsetting it.
@@ -303,17 +304,17 @@
 
     <event name="request_set_maximized">
       <description summary="server requests that the client set maximized">
-       Event sent by the compositor to request the client 
-       go to a maximized state. It's the client's responsibility to call 
set_maximized
-       and actually trigger the maximized state.
+       Event sent by the compositor to request the client go to a
+       maximized state. It's the client's responsibility to call
+       set_maximized and actually trigger the maximized state.
       </description>
     </event>
 
     <event name="request_unset_maximized">
       <description summary="server requests that the client unset maximized">
-       Event sent by the compositor to request the client
-       leave the maximized state. It's the client's responsibility to call 
unset_maximized
-       and actually leave the maximized state.
+       Event sent by the compositor to request the client leave the
+       maximized state. It's the client's responsibility to call
+       unset_maximized and actually leave the maximized state.
       </description>
     </event>
 
@@ -324,20 +325,20 @@
        After this request, the compositor will send a configure event
        with the new output size minus panel and other MW decorations.
 
-       This request informs the compositor that the next attached buffer
-       committed will be in a maximized state. The buffer size should be the
-       same size as the size informed in the configure event, if the client
-       doesn't want to leave any empty area.
+       This request informs the compositor that the next attached
+       buffer committed will be in a maximized state. The buffer size
+       should be the same size as the size informed in the configure
+       event, if the client doesn't want to leave any empty area.
 
-       In other words: the next attached buffer after set_maximized is the new
-       maximized buffer. And the surface will be positioned at the maximized
-       position on commit.
+       In other words: the next attached buffer after set_maximized is
+       the new maximized buffer. And the surface will be positioned at
+       the maximized position on commit.
 
-       A simple way to synchronize and wait for the correct configure event is
-       to use a wl_display.sync request right after the set_maximized request.
-       When the sync callback returns, the last configure event received just
-       before it will be the correct one, and should contain the right size
-       for the surface to maximize.
+       A simple way to synchronize and wait for the correct configure
+       event is to use a wl_display.sync request right after the
+       set_maximized request.  When the sync callback returns, the last
+       configure event received just before it will be the correct one,
+       and should contain the right size for the surface to maximize.
 
        Setting one state won't unset another state. Use
        xdg_surface.unset_maximized for unsetting it.
@@ -362,16 +363,16 @@
 
     <event name="focused_set">
       <description summary="surface was focused">
-       Event sent when this surface has been
-       activated. Window decorations should be updated accordingly.
+       Event sent when this surface has been activated. Window
+       decorations should be updated accordingly.
       </description>
     </event>
 
     <event name="focused_unset">
       <description summary="surface was unfocused">
-       Event sent when this surface has been
-       deactivated, because another surface has been activated. Window
-       decorations should be updated accordingly.
+       Event sent when this surface has been deactivated, because
+       another surface has been activated. Window decorations should be
+       updated accordingly.
       </description>
     </event>
   </interface>
@@ -381,15 +382,15 @@
       An interface for desktop-style popups/menus, implemented via a
       transient wl_surface and a pointer grab.
 
-      If there is an existing implicit grab, it will be changed to 
owner-events mode,
-      and the popup grab will continue after the implicit grab ends
-      (i.e. releasing the mouse button does not cause the popup to be
-      unmapped).
+      If there is an existing implicit grab, it will be changed to
+      owner-events mode, and the popup grab will continue after the
+      implicit grab ends (i.e. releasing the mouse button does not cause
+      the popup to be unmapped).
 
       The popup grab lasts until the window is destroyed or a mouse
       button is pressed in another client's window.  A click in any of
-      the client's surfaces is reported as normal, but clicks in
-      other clients' surfaces will be discarded and trigger the callback.
+      the client's surfaces is reported as normal, but clicks in other
+      clients' surfaces will be discarded and trigger the callback.
 
       The x and y parameters specify the locations of the upper left
       corner of the surface relative to the upper left corner of the
@@ -410,8 +411,8 @@
 
     <request name="pong">
       <description summary="respond to a ping event">
-        A client must respond to a ping event with a pong request or
-        the display server may deem the client unresponsive.
+       A client must respond to a ping event with a pong request or the
+       display server may deem the client unresponsive.
       </description>
       <arg name="serial" type="uint" summary="serial of the ping event"/>
     </request>
@@ -426,9 +427,9 @@
 
     <event name="popup_done">
       <description summary="popup interaction is done">
-       The popup_done event is sent when a popup grab is broken,
-       that is, when the users clicks a surface that doesn't belong
-       to the client owning the popup surface.
+       The popup_done event is sent when a popup grab is broken, that
+       is, when the users clicks a surface that doesn't belong to the
+       client owning the popup surface.
       </description>
       <arg name="serial" type="uint" summary="serial of the implicit grab on 
the pointer"/>
     </event>
-- 
1.7.9.5
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Reply via email to