[PATCH 2/2] protocol: Reformat xdg-shell and desktop protocol text to 72 chars
Bryce W. Harrington
b.harrington at samsung.com
Mon Jan 27 15:09:21 PST 2014
Signed-off-by: Bryce Harrington <b.harrington at 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
More information about the wayland-devel
mailing list