From e7183fb762bc4b1724aef563c53286756357846c Mon Sep 17 00:00:00 2001
From: Roman Gilg <subdiff@gmail.com>
Date: Tue, 15 Jun 2021 13:10:06 +0200
Subject: [PATCH] xdg-activation: use rst inline code
rst requires two backticks to format text as inline code.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
---
staging/xdg-activation/x11-interoperation.rst | 20 +++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/staging/xdg-activation/x11-interoperation.rst b/staging/xdg-activation/x11-interoperation.rst
index 5ebdd764..83196e91 100644
--- a/staging/xdg-activation/x11-interoperation.rst
+++ b/staging/xdg-activation/x11-interoperation.rst
@@ -5,12 +5,12 @@ Interoperation with X11
The former
`X11 Startup notification protocol <https://cgit.freedesktop.org/startup-notification/tree/doc/startup-notification.txt>`_
-defines the use of the DESKTOP_STARTUP_ID environment variable to propagate
+defines the use of the ``DESKTOP_STARTUP_ID`` environment variable to propagate
startup sequences ("activation tokens" in this protocol) between launcher and
launchee.
These startup sequence IDs are defined as a globally unique string with a
-`[unique]_TIME[timestamp]` format, where the ID as a whole is used for startup
+``[unique]_TIME[timestamp]`` format, where the ID as a whole is used for startup
notification and the timestamp is used for focus requests and focus stealing
prevention.
@@ -22,11 +22,11 @@ Scenario 1. Wayland client spawns X11 client
--------------------------------------------
1. Wayland client requests token.
-2. Wayland client spawns X11 client, sets `$DESKTOP_STARTUP_ID` in its
+2. Wayland client spawns X11 client, sets ``$DESKTOP_STARTUP_ID`` in its
environment with the token string.
3. X11 client starts.
-4. X11 client sends startup-notification `remove` message with the activation
- `$DESKTOP_STARTUP_ID` content.
+4. X11 client sends startup-notification ``remove`` message with the activation
+ ``$DESKTOP_STARTUP_ID`` content.
5. Compositor receives startup notification message, matches ID with
the common pool.
6. The startup feedback is finished.
@@ -37,14 +37,14 @@ Scenario 2. X11 client spawns Wayland client
--------------------------------------------
1. X11 client builds a "globally unique" ID
-2. X11 client sends startup-notification `new` message with the ID.
+2. X11 client sends startup-notification ``new`` message with the ID.
3. Compositor receives startup notification message, adds the ID to
the common pool.
-4. X11 client spawns Wayland client, sets `$DESKTOP_STARTUP_ID` in its
+4. X11 client spawns Wayland client, sets ``$DESKTOP_STARTUP_ID`` in its
environment.
5. Wayland client starts.
6. Wayland client sets the activation token, as received from
- `$DESKTOP_STARTUP_ID`.
+ ``$DESKTOP_STARTUP_ID``.
7. Compositor receives the request, matches ID with the common pool
8. The startup feedback is finished.
9. Wayland client requests surface activation.
@@ -53,12 +53,12 @@ Scenario 2. X11 client spawns Wayland client
Caveats
-------
-- For legacy reasons, the usage of `$DESKTOP_STARTUP_ID` (even if as a
+- For legacy reasons, the usage of ``$DESKTOP_STARTUP_ID`` (even if as a
fallback) should be observed in compositors and clients that are
concerned with X11 interoperation.
- Depending on the X11 startup-notification implementation in use by the
- compositor, the usage of the `_TIME[timestamp]` suffix may be mandatory
+ compositor, the usage of the ``_TIME[timestamp]`` suffix may be mandatory
for its correct behavior in the first scenario, the startup-notification
reference library is one such implementation. Compositors may work
this around by adding a matching suffix to the generated activation tokens.
--
GitLab