[PATCH wayland-protocols 00/19] Correct writing errors

[Yong Bakos]

From: Yong Bakos <***@humanoriented.com>

This v1 patchset consists of spelling, grammar and minor formatting
changes to all protocol xml files. The approach here is to be
minimally invasive and to not impart stylistic changes; only corrections
and consistency changes have been made, with the motivation of accuracy and
clarity of documentation.

Note: Only #16 affects a protocol (fullscreen-shell) directly, by correcting
a parameter name.

Any changes on the grounds of 'consistency' were made to reflect either:

a) the majority of the content in the specific xml doc itself
b) the current convention followed by protocol writers, including
wayland.xml

In other words, I hope you will find them non-opinionated. Apologies for
the rather verbose patchset, but this should allow easier decision making
and hopefully merging. Thanks for reviewing!

yong



Yong Bakos (19):
readme: Correct spelling and grammar
presentation-time: Correct minor grammar errors
xdg-shell: Downcase summary values consistently
xdg-shell: Remove inconsistent spacing
xdg-shell: Adjust articles and correct grammar
text-input: Fix indentation and paragraph whitespace
text-input: Rename text-input to text_input
text-input: Correct grammar
tablet: Adjust vertical whitespace for consistency
tablet: Correct grammar and punctuation
relative-pointer: Correct spelling error, one capitalization, and
minor space
pointer-gestures: Correct pluralization, one space, minor vertical
whitespace
pointer-constraints: Correct spelling, grammar and consistency
linux-dmabuf: Add missing articles and punctuation, adjust minor
whitespace
input-method: Correct grammar, add missing line break
fullscreen-shell: Correct spelling of parameter name
fullscreen-shell: Correct grammar, punctuation, minor naming and space
pointer-gestures: Add missing xml declaration
fullscreen-shell: Add missing xml declaration

README | 14 ++--
stable/presentation-time/presentation-time.xml | 6 +-
.../fullscreen-shell-unstable-v1.xml | 19 +++--
unstable/input-method/input-method-unstable-v1.xml | 40 ++++++-----
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml | 18 +++--
.../pointer-constraints-unstable-v1.xml | 16 ++---
.../pointer-gestures-unstable-v1.xml | 9 ++-
.../relative-pointer-unstable-v1.xml | 8 +--
unstable/tablet/tablet-unstable-v1.xml | 28 ++++----
unstable/text-input/text-input-unstable-v1.xml | 82 +++++++++++-----------
unstable/xdg-shell/xdg-shell-unstable-v5.xml | 30 ++++----
11 files changed, 142 insertions(+), 128 deletions(-)

--
2.7.2

[Yong Bakos]

From: Yong Bakos <***@humanoriented.com>

Signed-off-by: Yong Bakos <***@humanoriented.com>
---
unstable/xdg-shell/xdg-shell-unstable-v5.xml | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v5.xml b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
index f737f06..584d1fa 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v5.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
@@ -332,7 +332,7 @@
values and documenting the range they chose in this description.
They are not required to document the values for the range that they
chose. Ideally, any good extensions from a desktop environment should
- make its way into standardization into this enum.
+ make their way into standardization with this enum.

The current reserved ranges are:

@@ -380,7 +380,7 @@

If the width or height arguments are zero, it means the client
should decide its own window dimension. This may happen when the
- compositor need to configure the state of the surface but doesn't
+ compositor needs to configure the state of the surface but doesn't
have any information about any previous or expected dimension.

The states listed in the event specify how the width/height
@@ -388,7 +388,7 @@
drawn.

Clients should arrange their surface for the new size and
- states, and then send a ack_configure request with the serial
+ states, and then send an ack_configure request with the serial
sent in this configure event at some point before committing
the new surface.

@@ -537,13 +537,13 @@
<event name="close">
<description summary="surface wants to be closed">
The close event is sent by the compositor when the user
- wants the surface to be closed. This should be equivalent to
+ wants the window to be closed. This should be equivalent to
the user clicking the close button in client-side decorations,
- if your application has any...
+ if your application has any.

- This is only a request that the user intends to close your
+ This is only a request that the user intends to close the
window. The client may choose to ignore this request, or show
- a dialog to ask the user to save their data...
+ a dialog to ask the user to save their data, etc.
</description>
</event>
</interface>

[Yong Bakos]

From: Yong Bakos <***@humanoriented.com>

Replace the tab indentation of the MIT license with appropriate spaces.
Add one missing line break between two description paragraphs.
Adjust two line breaks to keep descriptions under 80 chars / line.

Signed-off-by: Yong Bakos <***@humanoriented.com>
---
unstable/text-input/text-input-unstable-v1.xml | 46 ++++++++++++++------------
1 file changed, 24 insertions(+), 22 deletions(-)

diff --git a/unstable/text-input/text-input-unstable-v1.xml b/unstable/text-input/text-input-unstable-v1.xml
index 1d00a52..4e558b5 100644
--- a/unstable/text-input/text-input-unstable-v1.xml
+++ b/unstable/text-input/text-input-unstable-v1.xml
@@ -4,24 +4,24 @@
<copyright>
Copyright © 2012, 2013 Intel Corporation

- 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.
+ 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.
</copyright>

<interface name="zwp_text_input_v1" version="1">
@@ -30,6 +30,7 @@
methods to applications. A text-input object is created from a
wl_text_input_manager and corresponds typically to a text entry in an
application.
+
Requests are used to activate/deactivate the text-input object and set
state information like surrounding and selected text or the content type.
The information about entered text is sent to the text-input object via
@@ -60,6 +61,7 @@
<description summary="request activation">
Requests the text-input object to be activated (typically when the
text entry gets focus).
+
The seat argument is a wl_seat which maintains the focus for this
activation. The surface argument is a wl_surface assigned to the
text-input object and tracked for focus lost. The enter event
@@ -182,8 +184,8 @@
format language tag.

It could be used for example in a word processor to indicate language of
- currently edited document or in an instant message application which tracks
- languages of contacts.
+ currently edited document or in an instant message application which
+ tracks languages of contacts.
</description>
<arg name="language" type="string"/>
</request>
@@ -341,8 +343,8 @@

<event name="language">
<description summary="language">
- Sets the language of the input text. The "language" argument is a RFC-3066
- format language tag.
+ Sets the language of the input text. The "language" argument is a
+ RFC-3066 format language tag.
</description>
<arg name="serial" type="uint" summary="serial of the latest known text input state"/>
<arg name="language" type="string"/>

[Yong Bakos]

From: Yong Bakos <***@humanoriented.com>

Interface names are lower_snake_case, and corresponding descriptions
should match, for accuracy and clarity. This renaming only affects
description text, to follow the convention that exists elswhere in
this protocol document and in other protocol docs, when referring to
interface names.

Signed-off-by: Yong Bakos <***@humanoriented.com>
---
unstable/text-input/text-input-unstable-v1.xml | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/unstable/text-input/text-input-unstable-v1.xml b/unstable/text-input/text-input-unstable-v1.xml
index 4e558b5..cfb1495 100644
--- a/unstable/text-input/text-input-unstable-v1.xml
+++ b/unstable/text-input/text-input-unstable-v1.xml
@@ -27,13 +27,13 @@
<interface name="zwp_text_input_v1" version="1">
<description summary="text input">
An object used for text input. Adds support for text input and input
- methods to applications. A text-input object is created from a
+ methods to applications. A text_input object is created from a
wl_text_input_manager and corresponds typically to a text entry in an
application.

- Requests are used to activate/deactivate the text-input object and set
+ Requests are used to activate/deactivate the text_input object and set
state information like surrounding and selected text or the content type.
- The information about entered text is sent to the text-input object via
+ The information about entered text is sent to the text_input object via
the pre-edit and commit events. Using this interface removes the need
for applications to directly process hardware key events and compose text
out of them.
@@ -59,12 +59,12 @@

<request name="activate">
<description summary="request activation">
- Requests the text-input object to be activated (typically when the
+ Requests the text_input object to be activated (typically when the
text entry gets focus).

The seat argument is a wl_seat which maintains the focus for this
activation. The surface argument is a wl_surface assigned to the
- text-input object and tracked for focus lost. The enter event
+ text_input object and tracked for focus lost. The enter event
is emitted on successful activation.
</description>
<arg name="seat" type="object" interface="wl_seat"/>
@@ -73,7 +73,7 @@

<request name="deactivate">
<description summary="request deactivation">
- Requests the text-input object to be deactivated (typically when the
+ Requests the text_input object to be deactivated (typically when the
text entry lost focus). The seat argument is a wl_seat which was used
for activation.
</description>
@@ -201,7 +201,7 @@

<event name="enter">
<description summary="enter event">
- Notify the text-input object when it received focus. Typically in
+ Notify the text_input object when it received focus. Typically in
response to an activate request.
</description>
<arg name="surface" type="object" interface="wl_surface"/>
@@ -209,7 +209,7 @@

<event name="leave">
<description summary="leave event">
- Notify the text-input object when it lost focus. Either in response
+ Notify the text_input object when it lost focus. Either in response
to a deactivate request or when the assigned surface lost focus or was
destroyed.
</description>
@@ -371,12 +371,12 @@

<interface name="zwp_text_input_manager_v1" version="1">
<description summary="text input manager">
- A factory for text-input objects. This object is a global singleton.
+ A factory for text_input objects. This object is a global singleton.
</description>

<request name="create_text_input">
<description summary="create text input">
- Creates a new text-input object.
+ Creates a new text_input object.
</description>
<arg name="id" type="new_id" interface="zwp_text_input_v1"/>
</request>

[Yong Bakos]

From: Yong Bakos <***@humanoriented.com>

Add/remove vertial whitespace between xml elements
according to conventions elsewhere within this, and other,
protocol xml docs.

Signed-off-by: Yong Bakos <***@humanoriented.com>
---
unstable/tablet/tablet-unstable-v1.xml | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/unstable/tablet/tablet-unstable-v1.xml b/unstable/tablet/tablet-unstable-v1.xml
index 8e3ab6f..6075fef 100644
--- a/unstable/tablet/tablet-unstable-v1.xml
+++ b/unstable/tablet/tablet-unstable-v1.xml
@@ -1,5 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="tablet_unstable_v1">
+
<copyright>
Copyright 2014 © Stephen "Lyude" Chandler Paul
Copyright 2015-2016 © Red Hat, Inc.
@@ -25,6 +26,7 @@
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
</copyright>
+
<description summary="Wayland protocol for graphics tablets">
This description provides a high-level overview of the interplay between
the interfaces defined this protocol. For details, see the protocol
@@ -112,6 +114,7 @@
version number in the protocol and interface names are removed and the
interface version number is reset.
</description>
+
<interface name="zwp_tablet_manager_v1" version="1">
<description summary="controller object for graphic tablet devices">
An object that provides access to the graphics tablets available on this
@@ -634,4 +637,5 @@
</description>
</event>
</interface>
+
</protocol>

[Yong Bakos]

From: Yong Bakos <***@humanoriented.com>

Signed-off-by: Yong Bakos <***@humanoriented.com>
---
unstable/text-input/text-input-unstable-v1.xml | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/unstable/text-input/text-input-unstable-v1.xml b/unstable/text-input/text-input-unstable-v1.xml
index cfb1495..29a217e 100644
--- a/unstable/text-input/text-input-unstable-v1.xml
+++ b/unstable/text-input/text-input-unstable-v1.xml
@@ -106,7 +106,7 @@
UTF-8 encoded. Cursor is the byte offset within the
surrounding text. Anchor is the byte offset of the
selection anchor within the surrounding text. If there is no selected
- text anchor is the same as cursor.
+ text anchor, then it is the same as cursor.
</description>
<arg name="text" type="string"/>
<arg name="cursor" type="uint"/>
@@ -180,12 +180,12 @@
<request name="set_preferred_language">
<description summary="sets preferred language">
Sets a specific language. This allows for example a virtual keyboard to
- show a language specific layout. The "language" argument is a RFC-3066
+ show a language specific layout. The "language" argument is an RFC-3066
format language tag.

- It could be used for example in a word processor to indicate language of
- currently edited document or in an instant message application which
- tracks languages of contacts.
+ It could be used for example in a word processor to indicate the
+ language of the currently edited document or in an instant message
+ application which tracks languages of contacts.
</description>
<arg name="language" type="string"/>
</request>
@@ -217,7 +217,7 @@

<event name="modifiers_map">
<description summary="modifiers map">
- Transfer an array of 0-terminated modifiers names. The position in
+ Transfer an array of 0-terminated modifier names. The position in
the array is the index of the modifier as used in the modifiers
bitmask in the keysym event.
</description>
@@ -289,7 +289,7 @@
<description summary="commit">
Notify when text should be inserted into the editor widget. The text to
commit could be either just a single character after a key press or the
- result of some composing (pre-edit). It could be also an empty text
+ result of some composing (pre-edit). It could also be an empty text
when some text should be removed (see delete_surrounding_text) or when
the input cursor should be moved (see cursor_position).

@@ -330,7 +330,7 @@
Notify when a key event was sent. Key events should not be used
for normal text input operations, which should be done with
commit_string, delete_surrounding_text, etc. The key event follows
- the wl_keyboard key event convention. Sym is a XKB keysym, state a
+ the wl_keyboard key event convention. Sym is an XKB keysym, state a
wl_keyboard key_state. Modifiers are a mask for effective modifiers
(where the modifier indices are set by the modifiers_map event)
</description>
@@ -343,7 +343,7 @@

<event name="language">
<description summary="language">
- Sets the language of the input text. The "language" argument is a
+ Sets the language of the input text. The "language" argument is an
RFC-3066 format language tag.
</description>
<arg name="serial" type="uint" summary="serial of the latest known text input state"/>
@@ -360,8 +360,8 @@
<description summary="text direction">
Sets the text direction of input text.

- It is mainly needed for showing input cursor on correct side of the
- editor when there is no input yet done and making sure neutral
+ It is mainly needed for showing an input cursor on the correct side of
+ the editor when there is no input done yet and making sure neutral
direction text is laid out properly.
</description>
<arg name="serial" type="uint" summary="serial of the latest known text input state"/>

[Yong Bakos]

From: Yong Bakos <***@humanoriented.com>

Remove line breaks preceding closing interface tags, to match conventions
in this, and other, protocol xml docs.

Signed-off-by: Yong Bakos <***@humanoriented.com>
---
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
index 99d3b51..3b4861f 100644
--- a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
+++ b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
@@ -56,11 +56,11 @@
sub-system that might accept it.

To create a wl_buffer from one or more dmabufs, a client creates a
- zwp_linux_dmabuf_params_v1 object with zwp_linux_dmabuf_v1.create_params
+ zwp_linux_dmabuf_params_v1 object with a zwp_linux_dmabuf_v1.create_params
request. All planes required by the intended format are added with
- the 'add' request. Finally, 'create' request is issued. The server
- will reply with either 'created' event which provides the final
- wl_buffer or 'failed' event saying that it cannot use the dmabufs
+ the 'add' request. Finally, a 'create' request is issued. The server
+ will reply with either a 'created' event which provides the final
+ wl_buffer or a 'failed' event saying that it cannot use the dmabufs
provided.

Warning! The protocol described in this file is experimental and
@@ -84,7 +84,7 @@
<description summary="create a temporary object for buffer parameters">
This temporary object is used to collect multiple dmabuf handles into
a single batch to create a wl_buffer. It can only be used once and
- should be destroyed after an 'created' or 'failed' event has been
+ should be destroyed after a 'created' or 'failed' event has been
received.
</description>
<arg name="params_id" type="new_id" interface="zwp_linux_buffer_params_v1"
@@ -95,7 +95,7 @@
<description summary="supported buffer format">
This event advertises one buffer format that the server supports.
All the supported formats are advertised once when the client
- binds to this interface. A roundtrip after binding guarantees,
+ binds to this interface. A roundtrip after binding guarantees
that the client has received all supported formats.

For the definition of the format codes, see create request.
@@ -104,7 +104,6 @@
</description>
<arg name="format" type="uint" summary="DRM_FORMAT code"/>
</event>
-
</interface>

<interface name="zwp_linux_buffer_params_v1" version="1">
@@ -116,7 +115,7 @@

Single-planar formats only require one dmabuf, however
multi-planar formats may require more than one dmabuf. For all
- formats, 'add' request must be called once per plane (even if the
+ formats, an 'add' request must be called once per plane (even if the
underlying dmabuf fd is identical).

You must use consecutive plane indices ('plane_idx' argument for 'add')
@@ -244,7 +243,7 @@

This request can be sent only once in the object's lifetime, after
which the only legal request is destroy. This object should be
- destroyed after issuing 'create' request. Attempting to use this
+ destroyed after issuing a 'create' request. Attempting to use this
object after issuing 'create' raises ALREADY_USED protocol error.

It is not mandatory to issue 'create'. If a client wants to
@@ -278,7 +277,6 @@
zlinux_buffer_params object.
</description>
</event>
-
</interface>

</protocol>

[Yong Bakos]

From: Yong Bakos <***@humanoriented.com>

Correcting minor grammar and punctuation affords clarity.
Standardize the use of 'surface local coordinates' in lieu of 'surface relative'.
Capitalize Wayland where appropriate, similar to other occurences.

Signed-off-by: Yong Bakos <***@humanoriented.com>
---
unstable/tablet/tablet-unstable-v1.xml | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/unstable/tablet/tablet-unstable-v1.xml b/unstable/tablet/tablet-unstable-v1.xml
index 6075fef..907126c 100644
--- a/unstable/tablet/tablet-unstable-v1.xml
+++ b/unstable/tablet/tablet-unstable-v1.xml
@@ -37,7 +37,7 @@
binds to the tablet manager object which is just a proxy object. From
that, the client requests wp_tablet_manager.get_tablet_seat(wl_seat)
and that returns the actual interface that has all the tablets. With
- this indirection, we can avoid merging wp_tablet into the actual wayland
+ this indirection, we can avoid merging wp_tablet into the actual Wayland
protocol, a long-term benefit.

The wp_tablet_seat sends a "tablet added" event for each tablet
@@ -229,14 +229,14 @@
assigned by this request is the same as assigned by
wl_pointer.set_cursor meaning the same surface can be
used both as a wl_pointer cursor and a wp_tablet cursor. If the
- surface already has another role, it raises a protocol error
+ surface already has another role, it raises a protocol error.
The surface may be used on multiple tablets and across multiple
seats.
</description>
<arg name="serial" type="uint" summary="serial of the enter event"/>
<arg name="surface" type="object" interface="wl_surface" allow-null="true"/>
- <arg name="hotspot_x" type="int" summary="x coordinate in surface-relative coordinates"/>
- <arg name="hotspot_y" type="int" summary="y coordinate in surface-relative coordinates"/>
+ <arg name="hotspot_x" type="int" summary="x coordinate in surface local coordinates"/>
+ <arg name="hotspot_y" type="int" summary="y coordinate in surface local coordinates"/>
</request>

<request name="destroy" type="destructor">
@@ -356,7 +356,7 @@
<event name="removed">
<description summary="tool removed">
This event is sent when the tool is removed from the system and will
- send no further events. Should the physical tool comes back into
+ send no further events. Should the physical tool come back into
proximity later, a new wp_tablet_tool object will be created.

It is compositor-dependent when a tool is removed. A compositor may
@@ -449,8 +449,8 @@
<description summary="motion event">
Sent whenever a tablet tool moves.
</description>
- <arg name="x" type="fixed" summary="surface-relative x coordinate"/>
- <arg name="y" type="fixed" summary="surface-relative y coordinate"/>
+ <arg name="x" type="fixed" summary="x coordinate in surface local coordinates"/>
+ <arg name="y" type="fixed" summary="y coordinate in surface local coordinates"/>
</event>

<event name="pressure">
@@ -458,7 +458,7 @@
Sent whenever the pressure axis on a tool changes. The value of this
event is normalized to a value between 0 and 65535.

- Note that pressure may be nonzero even when a tool not in logical
+ Note that pressure may be nonzero even when a tool is not in logical
contact. See the down and up events for more details.
</description>
<arg name="pressure" type="uint" summary="The current pressure value"/>
@@ -527,7 +527,7 @@

<enum name="button_state">
<description summary="physical button state">
- Describes the physical state of a button which provoked the button event
+ Describes the physical state of a button that produced the button event.
</description>
<entry name="released" value="0" summary="button is not pressed"/>
<entry name="pressed" value="1" summary="button is pressed"/>
@@ -551,7 +551,7 @@
<event name="frame">
<description summary="frame event">
Marks the end of a series of axis and/or button updates from the
- tablet. The wayland protocol requires axis updates to be sent
+ tablet. The Wayland protocol requires axis updates to be sent
sequentially, however all events within a frame should be considered
one hardware event.
</description>
@@ -604,9 +604,9 @@
this wp_tablet. This information may be used to gather additional
information about the device, e.g. through libwacom.

- A device may have more than one device path, if so, multiple
+ A device may have more than one device path. If so, multiple
wp_tablet.path events are sent. A device may be emulated and not
- have a device path, in that case this event will not be sent.
+ have a device path, and in that case this event will not be sent.

The format of the path is unspecified, it may be a device node, a
sysfs path, or some other identifier. It is up to the client to

[Yong Bakos]

From: Yong Bakos <***@humanoriented.com>

Signed-off-by: Yong Bakos <***@humanoriented.com>
---
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml b/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
index 93f95b8..b32dd88 100644
--- a/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
+++ b/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
@@ -85,7 +85,7 @@
wl_display.sync request immediately after binding to ensure that they
receive all the capability events.
</description>
- <arg name="capabilty" type="uint"/>
+ <arg name="capability" type="uint"/>
</event>

<enum name="present_method">

[Yong Bakos]

Jason,
See below, this one patch affects the argument name of the
zwp_fullscreen_shell_v1#capability event param name.

yong

Post by Yong Bakos
---
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml b/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
index 93f95b8..b32dd88 100644
--- a/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
+++ b/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
@@ -85,7 +85,7 @@
wl_display.sync request immediately after binding to ensure that they
receive all the capability events.
</description>
- <arg name="capabilty" type="uint"/>
+ <arg name="capability" type="uint"/>
</event>
<enum name="present_method">
--
2.7.2

[Pekka Paalanen]

On Mon, 11 Apr 2016 17:30:21 -0500

Post by Yong Bakos
Jason,
See below, this one patch affects the argument name of the
zwp_fullscreen_shell_v1#capability event param name.
yong

Post by Yong Bakos
---
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml b/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
index 93f95b8..b32dd88 100644
--- a/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
+++ b/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
@@ -85,7 +85,7 @@
wl_display.sync request immediately after binding to ensure that they
receive all the capability events.
</description>
- <arg name="capabilty" type="uint"/>
+ <arg name="capability" type="uint"/>
</event>
<enum name="present_method">

Hi,

for C language bindings, I cannot see argument names making any
difference. We should usually refrain from changing them, but in this
case it is such an obvious typo that I'm ok with changing it. So have a
Reviewed-by: Pekka Paalanen <***@collabora.co.uk>

The fun question is, do any other language bindings actually care about
the names as API?

This is yet another undocumented conundrum about the Wayland XML
language.


Thanks,
pq

[Yong Bakos]

Post by Pekka Paalanen
On Mon, 11 Apr 2016 17:30:21 -0500

Post by Yong Bakos
Jason,
See below, this one patch affects the argument name of the
zwp_fullscreen_shell_v1#capability event param name.
yong

Post by Yong Bakos
---
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml b/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
index 93f95b8..b32dd88 100644
--- a/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
+++ b/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
@@ -85,7 +85,7 @@
wl_display.sync request immediately after binding to ensure that they
receive all the capability events.
</description>
- <arg name="capabilty" type="uint"/>
+ <arg name="capability" type="uint"/>
</event>
<enum name="present_method">

Hi,
for C language bindings, I cannot see argument names making any
difference. We should usually refrain from changing them, but in this
case it is such an obvious typo that I'm ok with changing it. So have a
The fun question is, do any other language bindings actually care about
the names as API?

If one were to try to generate bindings for dynamically typed languages,
such as Ruby/Python, or ones that have formal named parameters, like Swift,
then name changes would matter.

yong

Post by Pekka Paalanen
This is yet another undocumented conundrum about the Wayland XML
language.
Thanks,
pq

[Bryce Harrington]

Post by Pekka Paalanen
On Mon, 11 Apr 2016 17:30:21 -0500

Post by Yong Bakos
Jason,
See below, this one patch affects the argument name of the
zwp_fullscreen_shell_v1#capability event param name.
yong

Post by Yong Bakos
---
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml b/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
index 93f95b8..b32dd88 100644
--- a/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
+++ b/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
@@ -85,7 +85,7 @@
wl_display.sync request immediately after binding to ensure that they
receive all the capability events.
</description>
- <arg name="capabilty" type="uint"/>
+ <arg name="capability" type="uint"/>
</event>
<enum name="present_method">

Hi,
for C language bindings, I cannot see argument names making any
difference. We should usually refrain from changing them, but in this
case it is such an obvious typo that I'm ok with changing it. So have a

Alright, pushed:

a8d7dce..5eb2a8d master -> master

Bryce

Post by Pekka Paalanen
The fun question is, do any other language bindings actually care about
the names as API?
This is yet another undocumented conundrum about the Wayland XML
language.
Thanks,
pq
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIVAwUBVw+jxCNf5bQRqqqnAQgedw/+IuZkKUp2MYgYAOx22yKDkq5hGwtkfzLo
YTDd1WRWXQ7w5OgXVD3YOA01QpLnFcjetpVvXn0IU3j5qStJ6P2P2e15+5L+c6N4
siNiEEo5k1lc04R+1pmxMC8ud6LgX34OMkhf7/al4A5wYNdEMeikgiQ8nKQWsMzc
1nJVbkd0Ln5MtuBQpOWCmz/Js5T4RibwmcTnubMCV9rKZkjrX9/+qDjGAAjW+3GW
yPX+9AuBTJcNPrFbY7WmlC76WbAyh9cSapzUUdW9E784+sT0VHBWGGeyE/y1q9yt
duMdkSknAoWo4R+bnr/pZcwKPdjEaVyA838/FBCerMCAb2mlMKw9arIyvMhi5LeO
U3BhiCH3Jr3KFXObyar7+RTcq7OAVeTWVf8U2G2bWzuP6ItfV72ONoFx1gK1U740
c7YK+8m8Tw9to6KLDD4eT4R7NtCiJSSn/V0RpHK/BNzMcFB61WMivYCAlDy2TQ54
P/ZBLmyAPbdLDbEs4RBYvAFAj8V2t9KqVcQ8pxpuAZQiCCjJCx5P7wwHsXlo5K28
f9R2F5/pCPWu//Q9e/08xKyU57hWNOCX3uVbA1/o6rXtdVnzGq2fmmZstc23CrGh
eSORgSbrm4OYEhU7beAWkVv6X28JOSP4eD0bs1R70bLvFTedGS5x4N6y5LCxzePk
wgaVugZWS4w=
=UlFn
-----END PGP SIGNATURE-----
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[Yong Bakos]

From: Yong Bakos <***@humanoriented.com>

Signed-off-by: Yong Bakos <***@humanoriented.com>
---
unstable/pointer-gestures/pointer-gestures-unstable-v1.xml | 1 +
1 file changed, 1 insertion(+)

diff --git a/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml b/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml
index 26928d5..5b7132c 100644
--- a/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml
+++ b/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml
@@ -1,3 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
<protocol name="pointer_gestures_unstable_v1">

<interface name="zwp_pointer_gestures_v1" version="1">

[Yong Bakos]

From: Yong Bakos <***@humanoriented.com>

Add missing periods that terminate sentences.
Correct ARBITRARY_MODE to match the actual enum value name.
Adjust one post-period space to match the rest of the content.
Downcase summary description to match the rest of the document.
Add line breaks between sequential enum elements to match conventions
in this, and other, protocol xml docs.

Signed-off-by: Yong Bakos <***@humanoriented.com>
---
.../fullscreen-shell/fullscreen-shell-unstable-v1.xml | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml b/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
index b32dd88..f076ce5 100644
--- a/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
+++ b/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
@@ -1,6 +1,7 @@
<protocol name="fullscreen_shell_unstable_v1">
+
<interface name="zwp_fullscreen_shell_v1" version="1">
- <description summary="Displays a single surface per output">
+ <description summary="displays a single surface per output">
Displays a single surface per output.

This interface provides a mechanism for a single client to display
@@ -14,7 +15,7 @@
details about scaling and mode switches.

The client can have at most one surface per output at any time.
- Requesting a surface be presented on an output that already has a
+ Requesting a surface to be presented on an output that already has a
surface replaces the previously presented surface. Presenting a null
surface removes its content and effectively disables the output.
Exactly what happens when an output is "disabled" is
@@ -38,7 +39,7 @@

<request name="release" type="destructor">
<description summary="release the wl_fullscreen_shell interface">
- Release the binding from the wl_fullscreen_shell interface
+ Release the binding from the wl_fullscreen_shell interface.

This destroys the server-side object and frees this binding. If
the client binds to wl_fullscreen_shell multiple times, it may wish
@@ -52,7 +53,7 @@
are advertised one-at-a-time when the wl_fullscreen_shell interface is
bound. See the wl_fullscreen_shell.capability event for more details.

- ARBITRARY_MODE:
+ ARBITRARY_MODES:
This is a hint to the client that indicates that the compositor is
capable of setting practically any mode on its outputs. If this
capability is provided, wl_fullscreen_shell.present_surface_for_mode
@@ -174,7 +175,7 @@

<enum name="error">
<description summary="wl_fullscreen_shell error values">
- These errors can be emitted in response to wl_fullscreen_shell requests
+ These errors can be emitted in response to wl_fullscreen_shell requests.
</description>
<entry name="invalid_method" value="0" summary="present_method is not known"/>
</enum>
@@ -191,16 +192,18 @@
wl_fullscreen_shell_mode_feedback object.
</description>
</event>
+
<event name="mode_failed">
<description summary="mode switch failed">
This event indicates that the attempted mode switch operation
- failed. This may be because the requested output mode is not
+ failed. This may be because the requested output mode is not
possible or it may mean that the compositor does not want to allow it.

Upon receiving this event, the client should destroy the
wl_fullscreen_shell_mode_feedback object.
</description>
</event>
+
<event name="present_cancelled">
<description summary="mode switch cancelled">
This event indicates that the attempted mode switch operation was
@@ -212,4 +215,5 @@
</description>
</event>
</interface>
+
</protocol>

[Yong Bakos]

From: Yong Bakos <***@humanoriented.com>

Signed-off-by: Yong Bakos <***@humanoriented.com>
---
unstable/xdg-shell/xdg-shell-unstable-v5.xml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v5.xml b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
index 542491f..b845258 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v5.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
@@ -42,7 +42,7 @@
they implement using static_assert to ensure the protocol and
implementation versions match.
</description>
- <entry name="current" value="5" summary="Always the latest version"/>
+ <entry name="current" value="5" summary="always the latest version"/>
</enum>

<enum name="error">
@@ -138,7 +138,7 @@
</interface>

<interface name="xdg_surface" version="1">
- <description summary="A desktop window">
+ <description summary="a desktop window">
An interface that may be implemented by a wl_surface, for
implementations that provide a desktop-style user interface.

@@ -161,7 +161,7 @@
</description>

<request name="destroy" type="destructor">
- <description summary="Destroy the xdg_surface">
+ <description summary="destroy the xdg_surface">
Unmap and destroy the window. The window will be effectively
hidden from the user's point of view, and all state like
maximization, fullscreen, and so on, will be lost.

[Yong Bakos]

From: Yong Bakos <***@humanoriented.com>

Convert two two-space periods to one, consistent with the rest
of the content.
Adjusst vertical whitespace of final closing interface tag to match
conventions set forth in this, and other, protocol docs.

Signed-off-by: Yong Bakos <***@humanoriented.com>
---
unstable/xdg-shell/xdg-shell-unstable-v5.xml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v5.xml b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
index b845258..f737f06 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v5.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
@@ -38,7 +38,7 @@
<enum name="version">
<description summary="latest protocol version">
The 'current' member of this enum gives the version of the
- protocol. Implementations can compare this to the version
+ protocol. Implementations can compare this to the version
they implement using static_assert to ensure the protocol and
implementation versions match.
</description>
@@ -64,10 +64,10 @@

<request name="use_unstable_version">
<description summary="enable use of this unstable version">
- Negotiate the unstable version of the interface. This
+ Negotiate the unstable version of the interface. This
mechanism is in place to ensure client and server agree on the
unstable versions of the protocol that they speak or exit
- cleanly if they don't agree. This request will go away once
+ cleanly if they don't agree. This request will go away once
the xdg-shell protocol is stable.
</description>
<arg name="version" type="int"/>
@@ -206,7 +206,7 @@
service name.

The compositor shell will try to group application surfaces together
- by their app ID. As a best practice, it is suggested to select app
+ by their app ID. As a best practice, it is suggested to select app
ID's that match the basename of the application's .desktop file.
For example, "org.freedesktop.FooViewer" where the .desktop file is
"org.freedesktop.FooViewer.desktop".
@@ -620,6 +620,6 @@
point.
</description>
</event>
-
</interface>
+
</protocol>

[Yong Bakos]

From: Yong Bakos <***@humanoriented.com>

Adjust double-space after period to be consistent with all content.
Adjust vertical whitespace surrounding first and last protocol tag to
match conventions in this, and other, protocol xml docs.

Signed-off-by: Yong Bakos <***@humanoriented.com>
---
unstable/pointer-gestures/pointer-gestures-unstable-v1.xml | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml b/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml
index dad6293..26928d5 100644
--- a/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml
+++ b/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml
@@ -1,4 +1,5 @@
<protocol name="pointer_gestures_unstable_v1">
+
<interface name="zwp_pointer_gestures_v1" version="1">
<description summary="touchpad gestures">
A global interface to provide semantic touchpad gestures for a given
@@ -87,7 +88,7 @@
<event name="end">
<description summary="multi-finger swipe end">
This event is sent when a multi-finger swipe gesture ceases to
- be valid. This may happen when one or more finger is lifted or
+ be valid. This may happen when one or more fingers are lifted or
the gesture is cancelled.

When a gesture is cancelled, the client should undo state changes
@@ -106,7 +107,7 @@
gesture detected on an indirect input device such as a touchpad.
The gesture is usually initiated by multiple fingers moving towards
each other or away from each other, or by two or more fingers rotating
- around a logical center of gravity. The precise conditions of when
+ around a logical center of gravity. The precise conditions of when
such a gesture is detected are implementation-dependent.

A gesture consists of three stages: begin, update (optional) and end.
@@ -159,7 +160,7 @@
<event name="end">
<description summary="multi-finger pinch end">
This event is sent when a multi-finger pinch gesture ceases to
- be valid. This may happen when one or more finger is lifted or
+ be valid. This may happen when one or more fingers are lifted or
the gesture is cancelled.

When a gesture is cancelled, the client should undo state changes
@@ -171,4 +172,5 @@
<arg name="cancelled" type="int" summary="1 if the gesture was cancelled, 0 otherwise"/>
</event>
</interface>
+
</protocol>

[Yong Bakos]

From: Yong Bakos <***@humanoriented.com>

Adds one line between two sequential request elements, to match conventions
within this, and other, protocol xml docs.

Signed-off-by: Yong Bakos <***@humanoriented.com>
---
unstable/input-method/input-method-unstable-v1.xml | 40 ++++++++++++----------
1 file changed, 21 insertions(+), 19 deletions(-)

diff --git a/unstable/input-method/input-method-unstable-v1.xml b/unstable/input-method/input-method-unstable-v1.xml
index fbf1bf2..274eac8 100644
--- a/unstable/input-method/input-method-unstable-v1.xml
+++ b/unstable/input-method/input-method-unstable-v1.xml
@@ -26,7 +26,7 @@

<interface name="zwp_input_method_context_v1" version="1">
<description summary="input method context">
- Corresponds to a text input on input method side. An input method context
+ Corresponds to a text input on the input method side. An input method context
is created on text input activation on the input method side. It allows to
receive information about the text input from the application via events.
Input method contexts do not keep state after deactivation and should be
@@ -73,11 +73,11 @@
<description summary="pre-edit string">
Send the pre-edit string text to the application text input.

- The commit text can be used to replace the preedit text on reset (for
+ The commit text can be used to replace the pre-edit text on reset (for
example on unfocus).

- Also previously sent preedit_style and preedit_cursor requests are
- processed bt the text_input also.
+ Previously sent preedit_style and preedit_cursor requests are also
+ processed by the text_input.
</description>
<arg name="serial" type="uint" summary="serial of the latest known text input state"/>
<arg name="text" type="string"/>
@@ -91,7 +91,7 @@
the composing text (as byte offset). Multiple styles can
be applied to a composing text.

- This request should be sent before sending preedit_string request.
+ This request should be sent before sending a preedit_string request.
</description>
<arg name="index" type="uint"/>
<arg name="length" type="uint"/>
@@ -105,15 +105,15 @@

When index is negative no cursor should be displayed.

- This request should be sent before sending preedit_string request.
+ This request should be sent before sending a preedit_string request.
</description>
<arg name="index" type="int"/>
</request>

<request name="delete_surrounding_text">
<description summary="delete text">
- This request will be handled on text_input side as part of a directly
- following commit_string request.
+ This request will be handled on the text_input side directly following
+ a commit_string request.
</description>
<arg name="index" type="int"/>
<arg name="length" type="uint"/>
@@ -122,14 +122,15 @@
<request name="cursor_position">
<description summary="set cursor to a new position">
Sets the cursor and anchor to a new position. Index is the new cursor
- position in bytes (when >= 0 relative to the end of inserted text
- else relative to beginning of inserted text). Anchor is the new anchor
- position in bytes (when >= 0 relative to the end of inserted text, else
- relative to beginning of inserted text). When there should be no
- selected text anchor should be the same as index.
-
- This request will be handled on text_input side as part of a directly
- following commit_string request.
+ position in bytes (when >= 0 relative to the end of inserted text,
+ otherwise relative to the beginning of the inserted text). Anchor is
+ the new anchor position in bytes (when >= 0 relative to the end of the
+ inserted text, otherwise relative to the beginning of the inserted
+ text). When there should be no selected text, anchor should be the same
+ as index.
+
+ This request will be handled on the text_input side directly following
+ a commit_string request.
</description>
<arg name="index" type="int"/>
<arg name="anchor" type="int"/>
@@ -143,7 +144,7 @@
<description summary="keysym">
Notify when a key event was sent. Key events should not be used for
normal text input operations, which should be done with commit_string,
- delete_surrounfing_text, etc. The key event follows the wl_keyboard key
+ delete_surrounding_text, etc. The key event follows the wl_keyboard key
event convention. Sym is a XKB keysym, state a wl_keyboard key_state.
</description>
<arg name="serial" type="uint" summary="serial of the latest known text input state"/>
@@ -184,7 +185,7 @@
<description summary="forward modifiers event">
Should be used when filtering key events with grab_keyboard.

- When the wl_keyboard::modifiers event should be also send to the
+ When the wl_keyboard::modifiers event should also be sent to the
client, forward it with this request. The arguments should be the ones
from the wl_keyboard::modifiers event.
</description>
@@ -199,6 +200,7 @@
<arg name="serial" type="uint" summary="serial of the latest known text input state"/>
<arg name="language" type="string"/>
</request>
+
<request name="text_direction">
<arg name="serial" type="uint" summary="serial of the latest known text input state"/>
<arg name="direction" type="uint"/>
@@ -241,7 +243,7 @@

<interface name="zwp_input_method_v1" version="1">
<description summary="input method">
- An input method object is responsible to compose text in response to
+ An input method object is responsible for composing text in response to
input from hardware or virtual keyboards. There is one input method
object per seat. On activate there is a new input method context object
created which allows the input method to communicate with the text input.

[Yong Bakos]

From: Yong Bakos <***@humanoriented.com>

Signed-off-by: Yong Bakos <***@humanoriented.com>
---
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml | 1 +
1 file changed, 1 insertion(+)

diff --git a/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml b/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
index f076ce5..7d141ee 100644
--- a/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
+++ b/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
@@ -1,3 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
<protocol name="fullscreen_shell_unstable_v1">

<interface name="zwp_fullscreen_shell_v1" version="1">

[Yong Bakos]

From: Yong Bakos <***@humanoriented.com>

Signed-off-by: Yong Bakos <***@humanoriented.com>
---
stable/presentation-time/presentation-time.xml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/stable/presentation-time/presentation-time.xml b/stable/presentation-time/presentation-time.xml
index dc4ae68..b8de4ca 100644
--- a/stable/presentation-time/presentation-time.xml
+++ b/stable/presentation-time/presentation-time.xml
@@ -33,7 +33,7 @@
The main feature of this interface is accurate presentation
timing feedback to ensure smooth video playback while maintaining
audio/video synchronization. Some features use the concept of a
- presentation clock, which is defined in presentation.clock_id
+ presentation clock, which is defined in the presentation.clock_id
event.

Request 'feedback' can be regarded as an additional wl_surface
@@ -79,7 +79,7 @@
multiple presentation_feedback objects are created for the same
submission, they will all deliver the same information.

- For details on what information is returned, see
+ For details on what information is returned, see the
presentation_feedback interface.
</description>

@@ -140,7 +140,7 @@
update because it was superseded or its surface destroyed,
and the content update is discarded.

- Once a presentation_feedback object has delivered an 'presented'
+ Once a presentation_feedback object has delivered a 'presented'
or 'discarded' event it is automatically destroyed.
</description>

[Yong Bakos]

From: Yong Bakos <***@humanoriented.com>

Downcase the protocol description summary.
Adjust two double-spaces to one, like the rest of the content.

Signed-off-by: Yong Bakos <***@humanoriented.com>
---
unstable/relative-pointer/relative-pointer-unstable-v1.xml | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/unstable/relative-pointer/relative-pointer-unstable-v1.xml b/unstable/relative-pointer/relative-pointer-unstable-v1.xml
index 2d2b0f3..24935a3 100644
--- a/unstable/relative-pointer/relative-pointer-unstable-v1.xml
+++ b/unstable/relative-pointer/relative-pointer-unstable-v1.xml
@@ -25,7 +25,7 @@
DEALINGS IN THE SOFTWARE.
</copyright>

- <description summary="Protocol for relative pointer motion events">
+ <description summary="protocol for relative pointer motion events">
This protocol specifies a set of interfaces used for making clients able to
receive relative pointer events not obstructed by barriers (such as the
monitor edge or other pointer barriers).
@@ -42,9 +42,9 @@

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
+ 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
+ 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.
@@ -111,7 +111,7 @@

Relative motions are not coupled to wl_pointer.motion events, and can be
sent in combination with such events, but also independently. There may
- also be scenarious where wl_pointer.motion is sent, but there is no
+ also be scenarios where wl_pointer.motion is sent, but there is no
relative motion. The order of an absolute and relative motion event
originating from the same physical motion is not guaranteed.

[Yong Bakos]

From: Yong Bakos <***@humanoriented.com>

Downcase the protocol summary description to match other protocols.
Replace 'surface-relative' with 'surface local' for consistency and clarity.

Signed-off-by: Yong Bakos <***@humanoriented.com>
---
.../pointer-constraints-unstable-v1.xml | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml b/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
index 6d090e5..3787b9e 100644
--- a/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
+++ b/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
@@ -25,12 +25,12 @@
DEALINGS IN THE SOFTWARE.
</copyright>

- <description summary="Protocol for constraining pointer motions">
+ <description summary="protocol for constraining pointer motions">
This protocol specifies a set of interfaces used for adding constraints to
the motion of a pointer. Possible constraints include confining pointer
motions to a given region, or locking it to its current position.

- In order to contrain the pointer, a client must first bind the global
+ In order to constrain the pointer, a client must first bind the global
interface "wp_pointer_constraints" which, if a compositor supports pointer
constraints, is exposed by the registry. Using the bound global object, the
client uses the request that corresponds to the type of constraint it wants
@@ -38,9 +38,9 @@

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
+ 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
+ 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.
@@ -49,7 +49,7 @@
<interface name="zwp_pointer_constraints_v1" version="1">
<description summary="constrain the movement of a pointer">
The global interface exposing pointer constraining functionality. It
- exposes two requests; lock_pointer for locking the pointer to its
+ exposes two requests: lock_pointer for locking the pointer to its
position, and confine_pointer for locking the pointer to a region.

The lock_pointer and confine_pointer requests create the objects
@@ -75,7 +75,7 @@
<enum name="lifetime">
<description summary="constraint lifetime">
These values represent different lifetime semantics. They are passed
- as argument to the factory requests to specify how the constraint
+ as arguments to the factory requests to specify how the constraint
lifetimes should be managed.
</description>
<entry name="oneshot" value="1">
@@ -233,9 +233,9 @@
</description>

<arg name="surface_x" type="fixed"
- summary="x coordinate in surface-relative coordinates"/>
+ summary="x coordinate in surface local coordinates"/>
<arg name="surface_y" type="fixed"
- summary="y coordinate in surface-relative coordinates"/>
+ summary="y coordinate in surface local coordinates"/>
</request>

<request name="set_region">

[Yong Bakos]

From: Yong Bakos <***@humanoriented.com>

Signed-off-by: Yong Bakos <***@humanoriented.com>
---
README | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/README b/README
index 324f873..da1f1d5 100644
--- a/README
+++ b/README
@@ -1,9 +1,9 @@
Wayland protocols
-----------------

-wayland-protocols contains Wayland protocols that adds functionality not
-available in the Wayland core protocol. Such protocols either adds
-completely new functionality, or extends the functionality of some other
+wayland-protocols contains Wayland protocols that add functionality not
+available in the Wayland core protocol. Such protocols either add
+completely new functionality, or extend the functionality of some other
protocol either in Wayland core, or some other protocol in
wayland-protocols.

@@ -29,7 +29,7 @@ A deprecated protocol is a protocol that has either been replaced by some
other protocol, or declared undesirable for some other reason. No more
changes will be made to a deprecated protocol.

-Depending on which of the above state the protocol is in, the protocol
+Depending on which of the above states the protocol is in, the protocol
is placed within the toplevel directory containing the protocols with the
same state. Stable protocols are placed in the +stable/+ directory,
unstable protocols are placed in the +unstable/+ directory, and
@@ -72,8 +72,8 @@ Unstable naming convention
Unstable protocols have a special naming convention in order to make it
possible to make discoverable backward incompatible changes.

-An unstable protocol has at least two versions; the major version which
-represents backward incompatible changes, and the minor versions which
+An unstable protocol has at least two versions: the major version, which
+represents backward incompatible changes, and the minor version, which
represents backward compatible changes to the interfaces in the protocol.

The major version is part of the XML file name, the protocol name in the
@@ -100,7 +100,7 @@ During the development of a new protocol it is possible that backward
incompatible changes are needed. Such a change needs to be represented
in the major and minor versions of the protocol.

-Assuming a backward incompatible change is needed, the procedure how to
+Assuming a backward incompatible change is needed, the procedure for how to
do so is the following:

. Make a copy of the XML file with the major version increased by +1+.

[Bryce Harrington]

Post by Yong Bakos
This v1 patchset consists of spelling, grammar and minor formatting
changes to all protocol xml files. The approach here is to be
minimally invasive and to not impart stylistic changes; only corrections
and consistency changes have been made, with the motivation of accuracy and
clarity of documentation.
Note: Only #16 affects a protocol (fullscreen-shell) directly, by correcting
a parameter name.
a) the majority of the content in the specific xml doc itself
b) the current convention followed by protocol writers, including
wayland.xml
In other words, I hope you will find them non-opinionated. Apologies for
the rather verbose patchset, but this should allow easier decision making
and hopefully merging. Thanks for reviewing!
yong
readme: Correct spelling and grammar
presentation-time: Correct minor grammar errors
xdg-shell: Downcase summary values consistently
xdg-shell: Remove inconsistent spacing
xdg-shell: Adjust articles and correct grammar
text-input: Fix indentation and paragraph whitespace
text-input: Rename text-input to text_input
text-input: Correct grammar
tablet: Adjust vertical whitespace for consistency
tablet: Correct grammar and punctuation
relative-pointer: Correct spelling error, one capitalization, and
minor space
pointer-gestures: Correct pluralization, one space, minor vertical
whitespace
pointer-constraints: Correct spelling, grammar and consistency
linux-dmabuf: Add missing articles and punctuation, adjust minor
whitespace
input-method: Correct grammar, add missing line break
fullscreen-shell: Correct spelling of parameter name
fullscreen-shell: Correct grammar, punctuation, minor naming and space
pointer-gestures: Add missing xml declaration
fullscreen-shell: Add missing xml declaration

Hi Yong,

Patches 1-2, 9-15, and 17-19 all R-b'd by me. All are obviously correct
copyediting to documentation, and I'll land them directly.

Since patch #16 affects protocol I've opted to omit it from speedy
landing. But the spelling fix is correct so +1 from me.

The xdg-shell and text-input patches I've left out just because there
are new versions for each of those protocols in the works, and I'm
hesistant on introducing a delta that could potentially cause problems.

For xdg-shell, its v6 is being developed in a branch:

https://cgit.freedesktop.org/wayland/wayland-protocols/

For text-input, it doesn't have a branch, but the most recent rev of its
v2 update is:

https://patchwork.freedesktop.org/patch/79435/

As I understand it, new major versions of protocols will be
co-installable, so presumably copyedits to the earlier versions of the
protocols won't cause merge conflicts or anything, so maybe these are
safe to land? However, maybe there might be some benefit during the
final stages of development if diffs between the two protocols aren't
cluttered up with copyedits? In any case, it probably makes sense to
copyedit the new versions of the protocols so we don't inadvertantly
regress the fixes when moving to the new versions.

So, first make sure to give review on text-input-v2 and xdg-shell-v6.
Second, I guess we should decide if copyedits to the older versions of
the protocols are worth doing, and if so should they be landed
separately from the new protocols or be included with them?

Post by Yong Bakos
README | 14 ++--
stable/presentation-time/presentation-time.xml | 6 +-
.../fullscreen-shell-unstable-v1.xml | 19 +++--
unstable/input-method/input-method-unstable-v1.xml | 40 ++++++-----
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml | 18 +++--
.../pointer-constraints-unstable-v1.xml | 16 ++---
.../pointer-gestures-unstable-v1.xml | 9 ++-
.../relative-pointer-unstable-v1.xml | 8 +--
unstable/tablet/tablet-unstable-v1.xml | 28 ++++----
unstable/text-input/text-input-unstable-v1.xml | 82 +++++++++++-----------
unstable/xdg-shell/xdg-shell-unstable-v5.xml | 30 ++++----
11 files changed, 142 insertions(+), 128 deletions(-)
--
2.7.2
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[Yong Bakos]

Post by Bryce Harrington

Post by Yong Bakos
This v1 patchset consists of spelling, grammar and minor formatting
changes to all protocol xml files. The approach here is to be
minimally invasive and to not impart stylistic changes; only corrections
and consistency changes have been made, with the motivation of accuracy and
clarity of documentation.
Note: Only #16 affects a protocol (fullscreen-shell) directly, by correcting
a parameter name.
a) the majority of the content in the specific xml doc itself
b) the current convention followed by protocol writers, including
wayland.xml
In other words, I hope you will find them non-opinionated. Apologies for
the rather verbose patchset, but this should allow easier decision making
and hopefully merging. Thanks for reviewing!
yong
readme: Correct spelling and grammar
presentation-time: Correct minor grammar errors
xdg-shell: Downcase summary values consistently
xdg-shell: Remove inconsistent spacing
xdg-shell: Adjust articles and correct grammar
text-input: Fix indentation and paragraph whitespace
text-input: Rename text-input to text_input
text-input: Correct grammar
tablet: Adjust vertical whitespace for consistency
tablet: Correct grammar and punctuation
relative-pointer: Correct spelling error, one capitalization, and
minor space
pointer-gestures: Correct pluralization, one space, minor vertical
whitespace
pointer-constraints: Correct spelling, grammar and consistency
linux-dmabuf: Add missing articles and punctuation, adjust minor
whitespace
input-method: Correct grammar, add missing line break
fullscreen-shell: Correct spelling of parameter name
fullscreen-shell: Correct grammar, punctuation, minor naming and space
pointer-gestures: Add missing xml declaration
fullscreen-shell: Add missing xml declaration

Hi Yong,
Patches 1-2, 9-15, and 17-19 all R-b'd by me. All are obviously correct
copyediting to documentation, and I'll land them directly.

Thank you!

Post by Bryce Harrington
Since patch #16 affects protocol I've opted to omit it from speedy
landing. But the spelling fix is correct so +1 from me.

I cc'd Jason E so hopefully he'll chime in.

Post by Bryce Harrington
The xdg-shell and text-input patches I've left out just because there
are new versions for each of those protocols in the works, and I'm
hesistant on introducing a delta that could potentially cause problems.
https://cgit.freedesktop.org/wayland/wayland-protocols/

Crap, I totally overlooked that branch and was working from master/HEAD.
I'll review again after Olivier's v6 patch is merged.

Post by Bryce Harrington
For text-input, it doesn't have a branch, but the most recent rev of its
https://patchwork.freedesktop.org/patch/79435/
As I understand it, new major versions of protocols will be
co-installable, so presumably copyedits to the earlier versions of the
protocols won't cause merge conflicts or anything, so maybe these are
safe to land? However, maybe there might be some benefit during the
final stages of development if diffs between the two protocols aren't
cluttered up with copyedits? In any case, it probably makes sense to
copyedit the new versions of the protocols so we don't inadvertantly
regress the fixes when moving to the new versions.
So, first make sure to give review on text-input-v2 and xdg-shell-v6.
Second, I guess we should decide if copyedits to the older versions of
the protocols are worth doing, and if so should they be landed
separately from the new protocols or be included with them?

I see what you're saying and thought about timing as well. My conclusion
was, "well, they're still unstable so ad hoc should be ok," but I do
understand your point.

yong

Post by Bryce Harrington

Post by Yong Bakos
README | 14 ++--
stable/presentation-time/presentation-time.xml | 6 +-
.../fullscreen-shell-unstable-v1.xml | 19 +++--
unstable/input-method/input-method-unstable-v1.xml | 40 ++++++-----
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml | 18 +++--
.../pointer-constraints-unstable-v1.xml | 16 ++---
.../pointer-gestures-unstable-v1.xml | 9 ++-
.../relative-pointer-unstable-v1.xml | 8 +--
unstable/tablet/tablet-unstable-v1.xml | 28 ++++----
unstable/text-input/text-input-unstable-v1.xml | 82 +++++++++++-----------
unstable/xdg-shell/xdg-shell-unstable-v5.xml | 30 ++++----
11 files changed, 142 insertions(+), 128 deletions(-)
--
2.7.2
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel