diff options
Diffstat (limited to 'contrib/SDL-3.2.8/wayland-protocols/xdg-activation-v1.xml')
| -rw-r--r-- | contrib/SDL-3.2.8/wayland-protocols/xdg-activation-v1.xml | 186 |
1 files changed, 186 insertions, 0 deletions
diff --git a/contrib/SDL-3.2.8/wayland-protocols/xdg-activation-v1.xml b/contrib/SDL-3.2.8/wayland-protocols/xdg-activation-v1.xml new file mode 100644 index 0000000..d87e633 --- /dev/null +++ b/contrib/SDL-3.2.8/wayland-protocols/xdg-activation-v1.xml | |||
| @@ -0,0 +1,186 @@ | |||
| 1 | <?xml version="1.0" encoding="UTF-8"?> | ||
| 2 | <protocol name="xdg_activation_v1"> | ||
| 3 | |||
| 4 | <copyright> | ||
| 5 | Copyright © 2020 Aleix Pol Gonzalez <aleixpol@kde.org> | ||
| 6 | Copyright © 2020 Carlos Garnacho <carlosg@gnome.org> | ||
| 7 | |||
| 8 | Permission is hereby granted, free of charge, to any person obtaining a | ||
| 9 | copy of this software and associated documentation files (the "Software"), | ||
| 10 | to deal in the Software without restriction, including without limitation | ||
| 11 | the rights to use, copy, modify, merge, publish, distribute, sublicense, | ||
| 12 | and/or sell copies of the Software, and to permit persons to whom the | ||
| 13 | Software is furnished to do so, subject to the following conditions: | ||
| 14 | |||
| 15 | The above copyright notice and this permission notice (including the next | ||
| 16 | paragraph) shall be included in all copies or substantial portions of the | ||
| 17 | Software. | ||
| 18 | |||
| 19 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR | ||
| 20 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, | ||
| 21 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL | ||
| 22 | THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER | ||
| 23 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING | ||
| 24 | FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER | ||
| 25 | DEALINGS IN THE SOFTWARE. | ||
| 26 | </copyright> | ||
| 27 | |||
| 28 | <description summary="Protocol for requesting activation of surfaces"> | ||
| 29 | The way for a client to pass focus to another toplevel is as follows. | ||
| 30 | |||
| 31 | The client that intends to activate another toplevel uses the | ||
| 32 | xdg_activation_v1.get_activation_token request to get an activation token. | ||
| 33 | This token is then passed to the client to be activated through a separate | ||
| 34 | band of communication. The client to be activated will then pass the token | ||
| 35 | it received to the xdg_activation_v1.activate request. The compositor can | ||
| 36 | then use this token to decide how to react to the activation request. | ||
| 37 | |||
| 38 | The token the activating client gets may be ineffective either already at | ||
| 39 | the time it receives it, for example if it was not focused, for focus | ||
| 40 | stealing prevention. The activating client will have no way to discover | ||
| 41 | the validity of the token, and may still forward it to the to be activated | ||
| 42 | client. | ||
| 43 | |||
| 44 | The created activation token may optionally get information attached to it | ||
| 45 | that can be used by the compositor to identify the application that we | ||
| 46 | intend to activate. This can for example be used to display a visual hint | ||
| 47 | about what application is being started. | ||
| 48 | |||
| 49 | Warning! The protocol described in this file is currently in the testing | ||
| 50 | phase. Backward compatible changes may be added together with the | ||
| 51 | corresponding interface version bump. Backward incompatible changes can | ||
| 52 | only be done by creating a new major version of the extension. | ||
| 53 | </description> | ||
| 54 | |||
| 55 | <interface name="xdg_activation_v1" version="1"> | ||
| 56 | <description summary="interface for activating surfaces"> | ||
| 57 | A global interface used for informing the compositor about applications | ||
| 58 | being activated or started, or for applications to request to be | ||
| 59 | activated. | ||
| 60 | </description> | ||
| 61 | |||
| 62 | <request name="destroy" type="destructor"> | ||
| 63 | <description summary="destroy the xdg_activation object"> | ||
| 64 | Notify the compositor that the xdg_activation object will no longer be | ||
| 65 | used. | ||
| 66 | |||
| 67 | The child objects created via this interface are unaffected and should | ||
| 68 | be destroyed separately. | ||
| 69 | </description> | ||
| 70 | </request> | ||
| 71 | |||
| 72 | <request name="get_activation_token"> | ||
| 73 | <description summary="requests a token"> | ||
| 74 | Creates an xdg_activation_token_v1 object that will provide | ||
| 75 | the initiating client with a unique token for this activation. This | ||
| 76 | token should be offered to the clients to be activated. | ||
| 77 | </description> | ||
| 78 | |||
| 79 | <arg name="id" type="new_id" interface="xdg_activation_token_v1"/> | ||
| 80 | </request> | ||
| 81 | |||
| 82 | <request name="activate"> | ||
| 83 | <description summary="notify new interaction being available"> | ||
| 84 | Requests surface activation. It's up to the compositor to display | ||
| 85 | this information as desired, for example by placing the surface above | ||
| 86 | the rest. | ||
| 87 | |||
| 88 | The compositor may know who requested this by checking the activation | ||
| 89 | token and might decide not to follow through with the activation if it's | ||
| 90 | considered unwanted. | ||
| 91 | |||
| 92 | Compositors can ignore unknown presentation tokens when an invalid | ||
| 93 | token is passed. | ||
| 94 | </description> | ||
| 95 | <arg name="token" type="string" summary="the activation token of the initiating client"/> | ||
| 96 | <arg name="surface" type="object" interface="wl_surface" | ||
| 97 | summary="the wl_surface to activate"/> | ||
| 98 | </request> | ||
| 99 | </interface> | ||
| 100 | |||
| 101 | <interface name="xdg_activation_token_v1" version="1"> | ||
| 102 | <description summary="an exported activation handle"> | ||
| 103 | An object for setting up a token and receiving a token handle that can | ||
| 104 | be passed as an activation token to another client. | ||
| 105 | |||
| 106 | The object is created using the xdg_activation_v1.get_activation_token | ||
| 107 | request. This object should then be populated with the app_id, surface | ||
| 108 | and serial information and committed. The compositor shall then issue a | ||
| 109 | done event with the token. In case the request's parameters are invalid, | ||
| 110 | the compositor will provide an invalid token. | ||
| 111 | </description> | ||
| 112 | |||
| 113 | <enum name="error"> | ||
| 114 | <entry name="already_used" value="0" | ||
| 115 | summary="The token has already been used previously"/> | ||
| 116 | </enum> | ||
| 117 | |||
| 118 | <request name="set_serial"> | ||
| 119 | <description summary="specifies the seat and serial of the activating event"> | ||
| 120 | Provides information about the seat and serial event that requested the | ||
| 121 | token. | ||
| 122 | |||
| 123 | Must be sent before commit. This information is optional. | ||
| 124 | </description> | ||
| 125 | <arg name="serial" type="uint" | ||
| 126 | summary="the serial of the event that triggered the activation"/> | ||
| 127 | <arg name="seat" type="object" interface="wl_seat" | ||
| 128 | summary="the wl_seat of the event"/> | ||
| 129 | </request> | ||
| 130 | |||
| 131 | <request name="set_app_id"> | ||
| 132 | <description summary="specifies the application being activated"> | ||
| 133 | The requesting client can specify an app_id to associate the token | ||
| 134 | being created with it. | ||
| 135 | |||
| 136 | Must be sent before commit. This information is optional. | ||
| 137 | </description> | ||
| 138 | <arg name="app_id" type="string" | ||
| 139 | summary="the application id of the client being activated."/> | ||
| 140 | </request> | ||
| 141 | |||
| 142 | <request name="set_surface"> | ||
| 143 | <description summary="specifies the application being activated"> | ||
| 144 | The requesting client can specify a surface to associate the token | ||
| 145 | being created with it. | ||
| 146 | |||
| 147 | Must be triggered before commit. This information is optional. | ||
| 148 | </description> | ||
| 149 | <arg name="surface" type="object" interface="wl_surface" | ||
| 150 | summary="the requesting surface"/> | ||
| 151 | </request> | ||
| 152 | |||
| 153 | <request name="commit"> | ||
| 154 | <description summary="issues the token request"> | ||
| 155 | Requests an activation token based on the different parameters that | ||
| 156 | have been offered through set_serial, set_surface and set_app_id. | ||
| 157 | </description> | ||
| 158 | </request> | ||
| 159 | |||
| 160 | <event name="done"> | ||
| 161 | <description summary="the exported activation token"> | ||
| 162 | The 'done' event contains the unique token of this activation request | ||
| 163 | and notifies that the provider is done. | ||
| 164 | |||
| 165 | Applications will typically receive the token through the | ||
| 166 | XDG_ACTIVATION_TOKEN environment variable as set by its launcher, and | ||
| 167 | should unset the environment variable right after this request, in | ||
| 168 | order to avoid propagating it to child processes. | ||
| 169 | |||
| 170 | Applications implementing the D-Bus interface org.freedesktop.Application | ||
| 171 | should get their token under XDG_ACTIVATION_TOKEN on their platform_data. | ||
| 172 | |||
| 173 | Presentation tokens may be transferred across clients through means not | ||
| 174 | described in this protocol. | ||
| 175 | </description> | ||
| 176 | <arg name="token" type="string" summary="the exported activation token"/> | ||
| 177 | </event> | ||
| 178 | |||
| 179 | <request name="destroy" type="destructor"> | ||
| 180 | <description summary="destroy the xdg_activation_token_v1 object"> | ||
| 181 | Notify the compositor that the xdg_activation_token_v1 object will no | ||
| 182 | longer be used. | ||
| 183 | </description> | ||
| 184 | </request> | ||
| 185 | </interface> | ||
| 186 | </protocol> | ||
