9 files changed, 12 insertions(+), 12 deletions(-)

M src/seat/example.md
M src/seat/touch.md
M src/seat/xkb.md
M src/surfaces-in-depth/subsurfaces.md
M src/xdg-shell-basics.md
M src/xdg-shell-basics/xdg-surface.md
M src/xdg-shell-basics/xdg-toplevel.md
M src/xdg-shell-in-depth/popups.md
M src/xdg-shell-in-depth/positioners.md

@@ 144,7 144,7 @@ object for seats which are capable of pointer input.
 ```
 
 This merits some explanation. Recall that `capabilities` is a bitmask of the
-kinds of devices supported by this seat - a bitwise AND (&) with a capability
+kinds of devices supported by this seat — a bitwise AND (&) with a capability
 will produce a non-zero value if supported. Then, if we have a pointer and have
 *not* already configured it, we take the first branch, using
 `wl_seat_get_pointer` to obtain a pointer reference and storing it in our state.


@@ 561,7 561,7 @@ and see your input printed into the log. Huzzah!
 
 Finally, we'll add support for touch-capable devices. Like pointers, a "frame"
 event exists for touch devices. However, they're further complicated by the
-possibility that mulitple touch points may be updated within a single frame.
+possibility that multiple touch points may be updated within a single frame.
 We'll add some more structures and enums to represent the accumulated state:
 
 ```diff


@@ 591,7 591,7 @@ We'll add some more structures and enums to represent the accumulated state:
 +};
 ```
 
-Note that I've arbitrarily choosen 10 touchpoints here, with the assumption that
+Note that I've arbitrarily chosen 10 touchpoints here, with the assumption that
 most users will only ever use that many fingers. For larger, multi-user touch
 screens, you may need a higher limit. Additionally, some touch hardware supports
 fewer than 10 touch points concurrently — 8 is also common, and hardware

@@ 129,4 129,4 @@ this knowledge in hand, let's update our example code.
 
 [^1]: Emphasis on "might" — don't make any assumptions based on the repeated use of a touch point ID.
 
-[^2]: This means that separate timestamps can be compared to each other to obtain the time between events, but are not comparible to wall-clock time.
+[^2]: This means that separate timestamps can be compared to each other to obtain the time between events, but are not comparable to wall-clock time.

@@ 34,7 34,7 @@ grab the header, `xkbcommon/xkbcommon.h`.[^1] Most programs which utilize
 xkbcommon will have to manage three objects:
 
 - xkb_context: a handle used for configuring other XKB resources
-- xkb_keymap: a mapping from scancodes to key symbls
+- xkb_keymap: a mapping from scancodes to key symbols
 - xkb_state: a state machine that turns key symbols into UTF-8 strings
 
 The process for setting this up usually goes as follows:

@@ 10,7 10,7 @@ pixel format with an RGBA user-interface or subtitles shown on top, using an
 OpenGL surface for your primary application interface and using subsurfaces to
 render window decorations in software, or moving around parts of the UI without
 having to redraw on the client. With the assistance of hardware planes, the
-compositor, too, might not even have to redraw anything for updates your
+compositor, too, might not even have to redraw anything for updating your
 subsurfaces. On embedded systems in particular, this can be especially useful
 when it fits your use-case. A cleverly designed application can take advantage
 of subsurfaces to be very efficient.

@@ 19,7 19,7 @@ on your system.
 
 `xdg_wm_base` is the only global defined by the specification, and it provides
 requests for creating each of the other objects you need. The most basic
-implementation starts by handling the "ping" event - when the compositor sends
+implementation starts by handling the "ping" event — when the compositor sends
 it, you should respond with a "pong" request in a timely manner to hint that you
 haven't become deadlocked. Another request deals with the creation of
 positioners, the objects mentioned earlier, and we'll save the details on these

@@ 21,7 21,7 @@ a `wl_surface`.
 The `xdg_surface` interface, in addition to requests for assigning a more
 specific role of toplevel or popup to your surface, also includes some important
 functionality common to both roles. Let's review these before we move on to the
-toplevel- and popup-specific semantics.
+toplevel and popup-specific semantics.
 
 ```xml
 <event name="configure">

@@ 46,7 46,7 @@ in the example code, but which may be appropriate for your application:
 </request>
 ```
 
-The title is often shown in window decorations, tasksbars, etc, whereas the app
+The title is often shown in window decorations, taskbars, etc, whereas the app
 ID is used to identify your application or group your windows together. You
 might utilize these by setting your window title to "Application windows &mdash; 
 The Wayland Protocol &mdash; Firefox", and your app ID to "firefox".

@@ 24,7 24,7 @@ request is used instead.
 The first and second arguments are reasonably self-explanatory, but the third
 one introduces a new concept: positioners. The purpose of the positioner is, as
 the name might suggest, to *position* the new popup. This is used to allow the
-compositor to participate in the positioning of popups using its priveleged
+compositor to participate in the positioning of popups using its privileged
 information, for example to avoid having the popup extend past the edge of the
 display. We'll discuss positioners in chapter 10.4, for now you can simply create
 one and pass it in without further configuration to achieve reasonably sane


@@ 72,7 72,7 @@ in chapter 10.4.
 ## Popup grabs
 
 Popup surfaces will often want to "grab" all input, for example to allow the
-user to use the arrow keys to select different menu items. This is facilitiated
+user to use the arrow keys to select different menu items. This is facilitated
 through the grab request:
 
 ```xml

@@ 8,7 8,7 @@ the point. Now, we'll explore this complex interface in depth.
 When you open a pop-up window, it's shown in a windowing system which has
 constraints that your client is not privy to. For example, Wayland clients are
 unaware of where their windows are being shown on-screen. Therefore, if you
-right click a window, the client does not poses the necessary information to
+right click a window, the client does not possess the necessary information to
 determine that the resulting pop-up might end up running itself off the edge of
 the screen. The positioner is designed to address these issues, by letting the
 client specify certain constraints in how the pop-up can be moved or resized,