M src/seat/example.md => src/seat/example.md +3 -3
@@ 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:
@@ 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
M src/seat/touch.md => src/seat/touch.md +1 -1
@@ 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.
M src/seat/xkb.md => src/seat/xkb.md +1 -1
@@ 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:
M src/surfaces-in-depth/subsurfaces.md => src/surfaces-in-depth/subsurfaces.md +1 -1
@@ 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.
M src/xdg-shell-basics.md => src/xdg-shell-basics.md +1 -1
@@ 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
M src/xdg-shell-basics/xdg-surface.md => src/xdg-shell-basics/xdg-surface.md +1 -1
@@ 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.
M src/xdg-shell-basics/xdg-toplevel.md => src/xdg-shell-basics/xdg-toplevel.md +1 -1
@@ 46,7 46,7 @@ in the example code, but which may be appropriate for your application:
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 —
The Wayland Protocol — Firefox", and your app ID to "firefox".
M => +2 -2
@@ 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:
M src/xdg-shell-in-depth/positioners.md => src/xdg-shell-in-depth/positioners.md +1 -1
@@ 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,