diff options
author | 3gg <3gg@shellblade.net> | 2025-08-30 16:53:58 -0700 |
---|---|---|
committer | 3gg <3gg@shellblade.net> | 2025-08-30 16:53:58 -0700 |
commit | 6aaedb813fa11ba0679c3051bc2eb28646b9506c (patch) | |
tree | 34acbfc9840e02cb4753e6306ea7ce978bf8b58e /src/contrib/SDL-3.2.20/wayland-protocols/xdg-shell.xml | |
parent | 8f228ade99dd3d4c8da9b78ade1815c9adf85c8f (diff) |
Update to SDL3
Diffstat (limited to 'src/contrib/SDL-3.2.20/wayland-protocols/xdg-shell.xml')
-rw-r--r-- | src/contrib/SDL-3.2.20/wayland-protocols/xdg-shell.xml | 1370 |
1 files changed, 1370 insertions, 0 deletions
diff --git a/src/contrib/SDL-3.2.20/wayland-protocols/xdg-shell.xml b/src/contrib/SDL-3.2.20/wayland-protocols/xdg-shell.xml new file mode 100644 index 0000000..777eaa7 --- /dev/null +++ b/src/contrib/SDL-3.2.20/wayland-protocols/xdg-shell.xml | |||
@@ -0,0 +1,1370 @@ | |||
1 | <?xml version="1.0" encoding="UTF-8"?> | ||
2 | <protocol name="xdg_shell"> | ||
3 | |||
4 | <copyright> | ||
5 | Copyright © 2008-2013 Kristian Høgsberg | ||
6 | Copyright © 2013 Rafael Antognolli | ||
7 | Copyright © 2013 Jasper St. Pierre | ||
8 | Copyright © 2010-2013 Intel Corporation | ||
9 | Copyright © 2015-2017 Samsung Electronics Co., Ltd | ||
10 | Copyright © 2015-2017 Red Hat Inc. | ||
11 | |||
12 | Permission is hereby granted, free of charge, to any person obtaining a | ||
13 | copy of this software and associated documentation files (the "Software"), | ||
14 | to deal in the Software without restriction, including without limitation | ||
15 | the rights to use, copy, modify, merge, publish, distribute, sublicense, | ||
16 | and/or sell copies of the Software, and to permit persons to whom the | ||
17 | Software is furnished to do so, subject to the following conditions: | ||
18 | |||
19 | The above copyright notice and this permission notice (including the next | ||
20 | paragraph) shall be included in all copies or substantial portions of the | ||
21 | Software. | ||
22 | |||
23 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR | ||
24 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, | ||
25 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL | ||
26 | THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER | ||
27 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING | ||
28 | FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER | ||
29 | DEALINGS IN THE SOFTWARE. | ||
30 | </copyright> | ||
31 | |||
32 | <interface name="xdg_wm_base" version="6"> | ||
33 | <description summary="create desktop-style surfaces"> | ||
34 | The xdg_wm_base interface is exposed as a global object enabling clients | ||
35 | to turn their wl_surfaces into windows in a desktop environment. It | ||
36 | defines the basic functionality needed for clients and the compositor to | ||
37 | create windows that can be dragged, resized, maximized, etc, as well as | ||
38 | creating transient windows such as popup menus. | ||
39 | </description> | ||
40 | |||
41 | <enum name="error"> | ||
42 | <entry name="role" value="0" summary="given wl_surface has another role"/> | ||
43 | <entry name="defunct_surfaces" value="1" | ||
44 | summary="xdg_wm_base was destroyed before children"/> | ||
45 | <entry name="not_the_topmost_popup" value="2" | ||
46 | summary="the client tried to map or destroy a non-topmost popup"/> | ||
47 | <entry name="invalid_popup_parent" value="3" | ||
48 | summary="the client specified an invalid popup parent surface"/> | ||
49 | <entry name="invalid_surface_state" value="4" | ||
50 | summary="the client provided an invalid surface state"/> | ||
51 | <entry name="invalid_positioner" value="5" | ||
52 | summary="the client provided an invalid positioner"/> | ||
53 | <entry name="unresponsive" value="6" | ||
54 | summary="the client didn’t respond to a ping event in time"/> | ||
55 | </enum> | ||
56 | |||
57 | <request name="destroy" type="destructor"> | ||
58 | <description summary="destroy xdg_wm_base"> | ||
59 | Destroy this xdg_wm_base object. | ||
60 | |||
61 | Destroying a bound xdg_wm_base object while there are surfaces | ||
62 | still alive created by this xdg_wm_base object instance is illegal | ||
63 | and will result in a defunct_surfaces error. | ||
64 | </description> | ||
65 | </request> | ||
66 | |||
67 | <request name="create_positioner"> | ||
68 | <description summary="create a positioner object"> | ||
69 | Create a positioner object. A positioner object is used to position | ||
70 | surfaces relative to some parent surface. See the interface description | ||
71 | and xdg_surface.get_popup for details. | ||
72 | </description> | ||
73 | <arg name="id" type="new_id" interface="xdg_positioner"/> | ||
74 | </request> | ||
75 | |||
76 | <request name="get_xdg_surface"> | ||
77 | <description summary="create a shell surface from a surface"> | ||
78 | This creates an xdg_surface for the given surface. While xdg_surface | ||
79 | itself is not a role, the corresponding surface may only be assigned | ||
80 | a role extending xdg_surface, such as xdg_toplevel or xdg_popup. It is | ||
81 | illegal to create an xdg_surface for a wl_surface which already has an | ||
82 | assigned role and this will result in a role error. | ||
83 | |||
84 | This creates an xdg_surface for the given surface. An xdg_surface is | ||
85 | used as basis to define a role to a given surface, such as xdg_toplevel | ||
86 | or xdg_popup. It also manages functionality shared between xdg_surface | ||
87 | based surface roles. | ||
88 | |||
89 | See the documentation of xdg_surface for more details about what an | ||
90 | xdg_surface is and how it is used. | ||
91 | </description> | ||
92 | <arg name="id" type="new_id" interface="xdg_surface"/> | ||
93 | <arg name="surface" type="object" interface="wl_surface"/> | ||
94 | </request> | ||
95 | |||
96 | <request name="pong"> | ||
97 | <description summary="respond to a ping event"> | ||
98 | A client must respond to a ping event with a pong request or | ||
99 | the client may be deemed unresponsive. See xdg_wm_base.ping | ||
100 | and xdg_wm_base.error.unresponsive. | ||
101 | </description> | ||
102 | <arg name="serial" type="uint" summary="serial of the ping event"/> | ||
103 | </request> | ||
104 | |||
105 | <event name="ping"> | ||
106 | <description summary="check if the client is alive"> | ||
107 | The ping event asks the client if it's still alive. Pass the | ||
108 | serial specified in the event back to the compositor by sending | ||
109 | a "pong" request back with the specified serial. See xdg_wm_base.pong. | ||
110 | |||
111 | Compositors can use this to determine if the client is still | ||
112 | alive. It's unspecified what will happen if the client doesn't | ||
113 | respond to the ping request, or in what timeframe. Clients should | ||
114 | try to respond in a reasonable amount of time. The “unresponsive” | ||
115 | error is provided for compositors that wish to disconnect unresponsive | ||
116 | clients. | ||
117 | |||
118 | A compositor is free to ping in any way it wants, but a client must | ||
119 | always respond to any xdg_wm_base object it created. | ||
120 | </description> | ||
121 | <arg name="serial" type="uint" summary="pass this to the pong request"/> | ||
122 | </event> | ||
123 | </interface> | ||
124 | |||
125 | <interface name="xdg_positioner" version="6"> | ||
126 | <description summary="child surface positioner"> | ||
127 | The xdg_positioner provides a collection of rules for the placement of a | ||
128 | child surface relative to a parent surface. Rules can be defined to ensure | ||
129 | the child surface remains within the visible area's borders, and to | ||
130 | specify how the child surface changes its position, such as sliding along | ||
131 | an axis, or flipping around a rectangle. These positioner-created rules are | ||
132 | constrained by the requirement that a child surface must intersect with or | ||
133 | be at least partially adjacent to its parent surface. | ||
134 | |||
135 | See the various requests for details about possible rules. | ||
136 | |||
137 | At the time of the request, the compositor makes a copy of the rules | ||
138 | specified by the xdg_positioner. Thus, after the request is complete the | ||
139 | xdg_positioner object can be destroyed or reused; further changes to the | ||
140 | object will have no effect on previous usages. | ||
141 | |||
142 | For an xdg_positioner object to be considered complete, it must have a | ||
143 | non-zero size set by set_size, and a non-zero anchor rectangle set by | ||
144 | set_anchor_rect. Passing an incomplete xdg_positioner object when | ||
145 | positioning a surface raises an invalid_positioner error. | ||
146 | </description> | ||
147 | |||
148 | <enum name="error"> | ||
149 | <entry name="invalid_input" value="0" summary="invalid input provided"/> | ||
150 | </enum> | ||
151 | |||
152 | <request name="destroy" type="destructor"> | ||
153 | <description summary="destroy the xdg_positioner object"> | ||
154 | Notify the compositor that the xdg_positioner will no longer be used. | ||
155 | </description> | ||
156 | </request> | ||
157 | |||
158 | <request name="set_size"> | ||
159 | <description summary="set the size of the to-be positioned rectangle"> | ||
160 | Set the size of the surface that is to be positioned with the positioner | ||
161 | object. The size is in surface-local coordinates and corresponds to the | ||
162 | window geometry. See xdg_surface.set_window_geometry. | ||
163 | |||
164 | If a zero or negative size is set the invalid_input error is raised. | ||
165 | </description> | ||
166 | <arg name="width" type="int" summary="width of positioned rectangle"/> | ||
167 | <arg name="height" type="int" summary="height of positioned rectangle"/> | ||
168 | </request> | ||
169 | |||
170 | <request name="set_anchor_rect"> | ||
171 | <description summary="set the anchor rectangle within the parent surface"> | ||
172 | Specify the anchor rectangle within the parent surface that the child | ||
173 | surface will be placed relative to. The rectangle is relative to the | ||
174 | window geometry as defined by xdg_surface.set_window_geometry of the | ||
175 | parent surface. | ||
176 | |||
177 | When the xdg_positioner object is used to position a child surface, the | ||
178 | anchor rectangle may not extend outside the window geometry of the | ||
179 | positioned child's parent surface. | ||
180 | |||
181 | If a negative size is set the invalid_input error is raised. | ||
182 | </description> | ||
183 | <arg name="x" type="int" summary="x position of anchor rectangle"/> | ||
184 | <arg name="y" type="int" summary="y position of anchor rectangle"/> | ||
185 | <arg name="width" type="int" summary="width of anchor rectangle"/> | ||
186 | <arg name="height" type="int" summary="height of anchor rectangle"/> | ||
187 | </request> | ||
188 | |||
189 | <enum name="anchor"> | ||
190 | <entry name="none" value="0"/> | ||
191 | <entry name="top" value="1"/> | ||
192 | <entry name="bottom" value="2"/> | ||
193 | <entry name="left" value="3"/> | ||
194 | <entry name="right" value="4"/> | ||
195 | <entry name="top_left" value="5"/> | ||
196 | <entry name="bottom_left" value="6"/> | ||
197 | <entry name="top_right" value="7"/> | ||
198 | <entry name="bottom_right" value="8"/> | ||
199 | </enum> | ||
200 | |||
201 | <request name="set_anchor"> | ||
202 | <description summary="set anchor rectangle anchor"> | ||
203 | Defines the anchor point for the anchor rectangle. The specified anchor | ||
204 | is used derive an anchor point that the child surface will be | ||
205 | positioned relative to. If a corner anchor is set (e.g. 'top_left' or | ||
206 | 'bottom_right'), the anchor point will be at the specified corner; | ||
207 | otherwise, the derived anchor point will be centered on the specified | ||
208 | edge, or in the center of the anchor rectangle if no edge is specified. | ||
209 | </description> | ||
210 | <arg name="anchor" type="uint" enum="anchor" | ||
211 | summary="anchor"/> | ||
212 | </request> | ||
213 | |||
214 | <enum name="gravity"> | ||
215 | <entry name="none" value="0"/> | ||
216 | <entry name="top" value="1"/> | ||
217 | <entry name="bottom" value="2"/> | ||
218 | <entry name="left" value="3"/> | ||
219 | <entry name="right" value="4"/> | ||
220 | <entry name="top_left" value="5"/> | ||
221 | <entry name="bottom_left" value="6"/> | ||
222 | <entry name="top_right" value="7"/> | ||
223 | <entry name="bottom_right" value="8"/> | ||
224 | </enum> | ||
225 | |||
226 | <request name="set_gravity"> | ||
227 | <description summary="set child surface gravity"> | ||
228 | Defines in what direction a surface should be positioned, relative to | ||
229 | the anchor point of the parent surface. If a corner gravity is | ||
230 | specified (e.g. 'bottom_right' or 'top_left'), then the child surface | ||
231 | will be placed towards the specified gravity; otherwise, the child | ||
232 | surface will be centered over the anchor point on any axis that had no | ||
233 | gravity specified. If the gravity is not in the ‘gravity’ enum, an | ||
234 | invalid_input error is raised. | ||
235 | </description> | ||
236 | <arg name="gravity" type="uint" enum="gravity" | ||
237 | summary="gravity direction"/> | ||
238 | </request> | ||
239 | |||
240 | <enum name="constraint_adjustment" bitfield="true"> | ||
241 | <description summary="constraint adjustments"> | ||
242 | The constraint adjustment value define ways the compositor will adjust | ||
243 | the position of the surface, if the unadjusted position would result | ||
244 | in the surface being partly constrained. | ||
245 | |||
246 | Whether a surface is considered 'constrained' is left to the compositor | ||
247 | to determine. For example, the surface may be partly outside the | ||
248 | compositor's defined 'work area', thus necessitating the child surface's | ||
249 | position be adjusted until it is entirely inside the work area. | ||
250 | |||
251 | The adjustments can be combined, according to a defined precedence: 1) | ||
252 | Flip, 2) Slide, 3) Resize. | ||
253 | </description> | ||
254 | <entry name="none" value="0"> | ||
255 | <description summary="don't move the child surface when constrained"> | ||
256 | Don't alter the surface position even if it is constrained on some | ||
257 | axis, for example partially outside the edge of an output. | ||
258 | </description> | ||
259 | </entry> | ||
260 | <entry name="slide_x" value="1"> | ||
261 | <description summary="move along the x axis until unconstrained"> | ||
262 | Slide the surface along the x axis until it is no longer constrained. | ||
263 | |||
264 | First try to slide towards the direction of the gravity on the x axis | ||
265 | until either the edge in the opposite direction of the gravity is | ||
266 | unconstrained or the edge in the direction of the gravity is | ||
267 | constrained. | ||
268 | |||
269 | Then try to slide towards the opposite direction of the gravity on the | ||
270 | x axis until either the edge in the direction of the gravity is | ||
271 | unconstrained or the edge in the opposite direction of the gravity is | ||
272 | constrained. | ||
273 | </description> | ||
274 | </entry> | ||
275 | <entry name="slide_y" value="2"> | ||
276 | <description summary="move along the y axis until unconstrained"> | ||
277 | Slide the surface along the y axis until it is no longer constrained. | ||
278 | |||
279 | First try to slide towards the direction of the gravity on the y axis | ||
280 | until either the edge in the opposite direction of the gravity is | ||
281 | unconstrained or the edge in the direction of the gravity is | ||
282 | constrained. | ||
283 | |||
284 | Then try to slide towards the opposite direction of the gravity on the | ||
285 | y axis until either the edge in the direction of the gravity is | ||
286 | unconstrained or the edge in the opposite direction of the gravity is | ||
287 | constrained. | ||
288 | </description> | ||
289 | </entry> | ||
290 | <entry name="flip_x" value="4"> | ||
291 | <description summary="invert the anchor and gravity on the x axis"> | ||
292 | Invert the anchor and gravity on the x axis if the surface is | ||
293 | constrained on the x axis. For example, if the left edge of the | ||
294 | surface is constrained, the gravity is 'left' and the anchor is | ||
295 | 'left', change the gravity to 'right' and the anchor to 'right'. | ||
296 | |||
297 | If the adjusted position also ends up being constrained, the resulting | ||
298 | position of the flip_x adjustment will be the one before the | ||
299 | adjustment. | ||
300 | </description> | ||
301 | </entry> | ||
302 | <entry name="flip_y" value="8"> | ||
303 | <description summary="invert the anchor and gravity on the y axis"> | ||
304 | Invert the anchor and gravity on the y axis if the surface is | ||
305 | constrained on the y axis. For example, if the bottom edge of the | ||
306 | surface is constrained, the gravity is 'bottom' and the anchor is | ||
307 | 'bottom', change the gravity to 'top' and the anchor to 'top'. | ||
308 | |||
309 | The adjusted position is calculated given the original anchor | ||
310 | rectangle and offset, but with the new flipped anchor and gravity | ||
311 | values. | ||
312 | |||
313 | If the adjusted position also ends up being constrained, the resulting | ||
314 | position of the flip_y adjustment will be the one before the | ||
315 | adjustment. | ||
316 | </description> | ||
317 | </entry> | ||
318 | <entry name="resize_x" value="16"> | ||
319 | <description summary="horizontally resize the surface"> | ||
320 | Resize the surface horizontally so that it is completely | ||
321 | unconstrained. | ||
322 | </description> | ||
323 | </entry> | ||
324 | <entry name="resize_y" value="32"> | ||
325 | <description summary="vertically resize the surface"> | ||
326 | Resize the surface vertically so that it is completely unconstrained. | ||
327 | </description> | ||
328 | </entry> | ||
329 | </enum> | ||
330 | |||
331 | <request name="set_constraint_adjustment"> | ||
332 | <description summary="set the adjustment to be done when constrained"> | ||
333 | Specify how the window should be positioned if the originally intended | ||
334 | position caused the surface to be constrained, meaning at least | ||
335 | partially outside positioning boundaries set by the compositor. The | ||
336 | adjustment is set by constructing a bitmask describing the adjustment to | ||
337 | be made when the surface is constrained on that axis. | ||
338 | |||
339 | If no bit for one axis is set, the compositor will assume that the child | ||
340 | surface should not change its position on that axis when constrained. | ||
341 | |||
342 | If more than one bit for one axis is set, the order of how adjustments | ||
343 | are applied is specified in the corresponding adjustment descriptions. | ||
344 | |||
345 | The default adjustment is none. | ||
346 | </description> | ||
347 | <arg name="constraint_adjustment" type="uint" | ||
348 | summary="bit mask of constraint adjustments"/> | ||
349 | </request> | ||
350 | |||
351 | <request name="set_offset"> | ||
352 | <description summary="set surface position offset"> | ||
353 | Specify the surface position offset relative to the position of the | ||
354 | anchor on the anchor rectangle and the anchor on the surface. For | ||
355 | example if the anchor of the anchor rectangle is at (x, y), the surface | ||
356 | has the gravity bottom|right, and the offset is (ox, oy), the calculated | ||
357 | surface position will be (x + ox, y + oy). The offset position of the | ||
358 | surface is the one used for constraint testing. See | ||
359 | set_constraint_adjustment. | ||
360 | |||
361 | An example use case is placing a popup menu on top of a user interface | ||
362 | element, while aligning the user interface element of the parent surface | ||
363 | with some user interface element placed somewhere in the popup surface. | ||
364 | </description> | ||
365 | <arg name="x" type="int" summary="surface position x offset"/> | ||
366 | <arg name="y" type="int" summary="surface position y offset"/> | ||
367 | </request> | ||
368 | |||
369 | <!-- Version 3 additions --> | ||
370 | |||
371 | <request name="set_reactive" since="3"> | ||
372 | <description summary="continuously reconstrain the surface"> | ||
373 | When set reactive, the surface is reconstrained if the conditions used | ||
374 | for constraining changed, e.g. the parent window moved. | ||
375 | |||
376 | If the conditions changed and the popup was reconstrained, an | ||
377 | xdg_popup.configure event is sent with updated geometry, followed by an | ||
378 | xdg_surface.configure event. | ||
379 | </description> | ||
380 | </request> | ||
381 | |||
382 | <request name="set_parent_size" since="3"> | ||
383 | <description summary=""> | ||
384 | Set the parent window geometry the compositor should use when | ||
385 | positioning the popup. The compositor may use this information to | ||
386 | determine the future state the popup should be constrained using. If | ||
387 | this doesn't match the dimension of the parent the popup is eventually | ||
388 | positioned against, the behavior is undefined. | ||
389 | |||
390 | The arguments are given in the surface-local coordinate space. | ||
391 | </description> | ||
392 | <arg name="parent_width" type="int" | ||
393 | summary="future window geometry width of parent"/> | ||
394 | <arg name="parent_height" type="int" | ||
395 | summary="future window geometry height of parent"/> | ||
396 | </request> | ||
397 | |||
398 | <request name="set_parent_configure" since="3"> | ||
399 | <description summary="set parent configure this is a response to"> | ||
400 | Set the serial of an xdg_surface.configure event this positioner will be | ||
401 | used in response to. The compositor may use this information together | ||
402 | with set_parent_size to determine what future state the popup should be | ||
403 | constrained using. | ||
404 | </description> | ||
405 | <arg name="serial" type="uint" | ||
406 | summary="serial of parent configure event"/> | ||
407 | </request> | ||
408 | </interface> | ||
409 | |||
410 | <interface name="xdg_surface" version="6"> | ||
411 | <description summary="desktop user interface surface base interface"> | ||
412 | An interface that may be implemented by a wl_surface, for | ||
413 | implementations that provide a desktop-style user interface. | ||
414 | |||
415 | It provides a base set of functionality required to construct user | ||
416 | interface elements requiring management by the compositor, such as | ||
417 | toplevel windows, menus, etc. The types of functionality are split into | ||
418 | xdg_surface roles. | ||
419 | |||
420 | Creating an xdg_surface does not set the role for a wl_surface. In order | ||
421 | to map an xdg_surface, the client must create a role-specific object | ||
422 | using, e.g., get_toplevel, get_popup. The wl_surface for any given | ||
423 | xdg_surface can have at most one role, and may not be assigned any role | ||
424 | not based on xdg_surface. | ||
425 | |||
426 | A role must be assigned before any other requests are made to the | ||
427 | xdg_surface object. | ||
428 | |||
429 | The client must call wl_surface.commit on the corresponding wl_surface | ||
430 | for the xdg_surface state to take effect. | ||
431 | |||
432 | Creating an xdg_surface from a wl_surface which has a buffer attached or | ||
433 | committed is a client error, and any attempts by a client to attach or | ||
434 | manipulate a buffer prior to the first xdg_surface.configure call must | ||
435 | also be treated as errors. | ||
436 | |||
437 | After creating a role-specific object and setting it up, the client must | ||
438 | perform an initial commit without any buffer attached. The compositor | ||
439 | will reply with initial wl_surface state such as | ||
440 | wl_surface.preferred_buffer_scale followed by an xdg_surface.configure | ||
441 | event. The client must acknowledge it and is then allowed to attach a | ||
442 | buffer to map the surface. | ||
443 | |||
444 | Mapping an xdg_surface-based role surface is defined as making it | ||
445 | possible for the surface to be shown by the compositor. Note that | ||
446 | a mapped surface is not guaranteed to be visible once it is mapped. | ||
447 | |||
448 | For an xdg_surface to be mapped by the compositor, the following | ||
449 | conditions must be met: | ||
450 | (1) the client has assigned an xdg_surface-based role to the surface | ||
451 | (2) the client has set and committed the xdg_surface state and the | ||
452 | role-dependent state to the surface | ||
453 | (3) the client has committed a buffer to the surface | ||
454 | |||
455 | A newly-unmapped surface is considered to have met condition (1) out | ||
456 | of the 3 required conditions for mapping a surface if its role surface | ||
457 | has not been destroyed, i.e. the client must perform the initial commit | ||
458 | again before attaching a buffer. | ||
459 | </description> | ||
460 | |||
461 | <enum name="error"> | ||
462 | <entry name="not_constructed" value="1" | ||
463 | summary="Surface was not fully constructed"/> | ||
464 | <entry name="already_constructed" value="2" | ||
465 | summary="Surface was already constructed"/> | ||
466 | <entry name="unconfigured_buffer" value="3" | ||
467 | summary="Attaching a buffer to an unconfigured surface"/> | ||
468 | <entry name="invalid_serial" value="4" | ||
469 | summary="Invalid serial number when acking a configure event"/> | ||
470 | <entry name="invalid_size" value="5" | ||
471 | summary="Width or height was zero or negative"/> | ||
472 | <entry name="defunct_role_object" value="6" | ||
473 | summary="Surface was destroyed before its role object"/> | ||
474 | </enum> | ||
475 | |||
476 | <request name="destroy" type="destructor"> | ||
477 | <description summary="destroy the xdg_surface"> | ||
478 | Destroy the xdg_surface object. An xdg_surface must only be destroyed | ||
479 | after its role object has been destroyed, otherwise | ||
480 | a defunct_role_object error is raised. | ||
481 | </description> | ||
482 | </request> | ||
483 | |||
484 | <request name="get_toplevel"> | ||
485 | <description summary="assign the xdg_toplevel surface role"> | ||
486 | This creates an xdg_toplevel object for the given xdg_surface and gives | ||
487 | the associated wl_surface the xdg_toplevel role. | ||
488 | |||
489 | See the documentation of xdg_toplevel for more details about what an | ||
490 | xdg_toplevel is and how it is used. | ||
491 | </description> | ||
492 | <arg name="id" type="new_id" interface="xdg_toplevel"/> | ||
493 | </request> | ||
494 | |||
495 | <request name="get_popup"> | ||
496 | <description summary="assign the xdg_popup surface role"> | ||
497 | This creates an xdg_popup object for the given xdg_surface and gives | ||
498 | the associated wl_surface the xdg_popup role. | ||
499 | |||
500 | If null is passed as a parent, a parent surface must be specified using | ||
501 | some other protocol, before committing the initial state. | ||
502 | |||
503 | See the documentation of xdg_popup for more details about what an | ||
504 | xdg_popup is and how it is used. | ||
505 | </description> | ||
506 | <arg name="id" type="new_id" interface="xdg_popup"/> | ||
507 | <arg name="parent" type="object" interface="xdg_surface" allow-null="true"/> | ||
508 | <arg name="positioner" type="object" interface="xdg_positioner"/> | ||
509 | </request> | ||
510 | |||
511 | <request name="set_window_geometry"> | ||
512 | <description summary="set the new window geometry"> | ||
513 | The window geometry of a surface is its "visible bounds" from the | ||
514 | user's perspective. Client-side decorations often have invisible | ||
515 | portions like drop-shadows which should be ignored for the | ||
516 | purposes of aligning, placing and constraining windows. | ||
517 | |||
518 | The window geometry is double buffered, and will be applied at the | ||
519 | time wl_surface.commit of the corresponding wl_surface is called. | ||
520 | |||
521 | When maintaining a position, the compositor should treat the (x, y) | ||
522 | coordinate of the window geometry as the top left corner of the window. | ||
523 | A client changing the (x, y) window geometry coordinate should in | ||
524 | general not alter the position of the window. | ||
525 | |||
526 | Once the window geometry of the surface is set, it is not possible to | ||
527 | unset it, and it will remain the same until set_window_geometry is | ||
528 | called again, even if a new subsurface or buffer is attached. | ||
529 | |||
530 | If never set, the value is the full bounds of the surface, | ||
531 | including any subsurfaces. This updates dynamically on every | ||
532 | commit. This unset is meant for extremely simple clients. | ||
533 | |||
534 | The arguments are given in the surface-local coordinate space of | ||
535 | the wl_surface associated with this xdg_surface, and may extend outside | ||
536 | of the wl_surface itself to mark parts of the subsurface tree as part of | ||
537 | the window geometry. | ||
538 | |||
539 | When applied, the effective window geometry will be the set window | ||
540 | geometry clamped to the bounding rectangle of the combined | ||
541 | geometry of the surface of the xdg_surface and the associated | ||
542 | subsurfaces. | ||
543 | |||
544 | The effective geometry will not be recalculated unless a new call to | ||
545 | set_window_geometry is done and the new pending surface state is | ||
546 | subsequently applied. | ||
547 | |||
548 | The width and height of the effective window geometry must be | ||
549 | greater than zero. Setting an invalid size will raise an | ||
550 | invalid_size error. | ||
551 | </description> | ||
552 | <arg name="x" type="int"/> | ||
553 | <arg name="y" type="int"/> | ||
554 | <arg name="width" type="int"/> | ||
555 | <arg name="height" type="int"/> | ||
556 | </request> | ||
557 | |||
558 | <request name="ack_configure"> | ||
559 | <description summary="ack a configure event"> | ||
560 | When a configure event is received, if a client commits the | ||
561 | surface in response to the configure event, then the client | ||
562 | must make an ack_configure request sometime before the commit | ||
563 | request, passing along the serial of the configure event. | ||
564 | |||
565 | For instance, for toplevel surfaces the compositor might use this | ||
566 | information to move a surface to the top left only when the client has | ||
567 | drawn itself for the maximized or fullscreen state. | ||
568 | |||
569 | If the client receives multiple configure events before it | ||
570 | can respond to one, it only has to ack the last configure event. | ||
571 | Acking a configure event that was never sent raises an invalid_serial | ||
572 | error. | ||
573 | |||
574 | A client is not required to commit immediately after sending | ||
575 | an ack_configure request - it may even ack_configure several times | ||
576 | before its next surface commit. | ||
577 | |||
578 | A client may send multiple ack_configure requests before committing, but | ||
579 | only the last request sent before a commit indicates which configure | ||
580 | event the client really is responding to. | ||
581 | |||
582 | Sending an ack_configure request consumes the serial number sent with | ||
583 | the request, as well as serial numbers sent by all configure events | ||
584 | sent on this xdg_surface prior to the configure event referenced by | ||
585 | the committed serial. | ||
586 | |||
587 | It is an error to issue multiple ack_configure requests referencing a | ||
588 | serial from the same configure event, or to issue an ack_configure | ||
589 | request referencing a serial from a configure event issued before the | ||
590 | event identified by the last ack_configure request for the same | ||
591 | xdg_surface. Doing so will raise an invalid_serial error. | ||
592 | </description> | ||
593 | <arg name="serial" type="uint" summary="the serial from the configure event"/> | ||
594 | </request> | ||
595 | |||
596 | <event name="configure"> | ||
597 | <description summary="suggest a surface change"> | ||
598 | The configure event marks the end of a configure sequence. A configure | ||
599 | sequence is a set of one or more events configuring the state of the | ||
600 | xdg_surface, including the final xdg_surface.configure event. | ||
601 | |||
602 | Where applicable, xdg_surface surface roles will during a configure | ||
603 | sequence extend this event as a latched state sent as events before the | ||
604 | xdg_surface.configure event. Such events should be considered to make up | ||
605 | a set of atomically applied configuration states, where the | ||
606 | xdg_surface.configure commits the accumulated state. | ||
607 | |||
608 | Clients should arrange their surface for the new states, and then send | ||
609 | an ack_configure request with the serial sent in this configure event at | ||
610 | some point before committing the new surface. | ||
611 | |||
612 | If the client receives multiple configure events before it can respond | ||
613 | to one, it is free to discard all but the last event it received. | ||
614 | </description> | ||
615 | <arg name="serial" type="uint" summary="serial of the configure event"/> | ||
616 | </event> | ||
617 | |||
618 | </interface> | ||
619 | |||
620 | <interface name="xdg_toplevel" version="6"> | ||
621 | <description summary="toplevel surface"> | ||
622 | This interface defines an xdg_surface role which allows a surface to, | ||
623 | among other things, set window-like properties such as maximize, | ||
624 | fullscreen, and minimize, set application-specific metadata like title and | ||
625 | id, and well as trigger user interactive operations such as interactive | ||
626 | resize and move. | ||
627 | |||
628 | Unmapping an xdg_toplevel means that the surface cannot be shown | ||
629 | by the compositor until it is explicitly mapped again. | ||
630 | All active operations (e.g., move, resize) are canceled and all | ||
631 | attributes (e.g. title, state, stacking, ...) are discarded for | ||
632 | an xdg_toplevel surface when it is unmapped. The xdg_toplevel returns to | ||
633 | the state it had right after xdg_surface.get_toplevel. The client | ||
634 | can re-map the toplevel by perfoming a commit without any buffer | ||
635 | attached, waiting for a configure event and handling it as usual (see | ||
636 | xdg_surface description). | ||
637 | |||
638 | Attaching a null buffer to a toplevel unmaps the surface. | ||
639 | </description> | ||
640 | |||
641 | <request name="destroy" type="destructor"> | ||
642 | <description summary="destroy the xdg_toplevel"> | ||
643 | This request destroys the role surface and unmaps the surface; | ||
644 | see "Unmapping" behavior in interface section for details. | ||
645 | </description> | ||
646 | </request> | ||
647 | |||
648 | <enum name="error"> | ||
649 | <entry name="invalid_resize_edge" value="0" summary="provided value is | ||
650 | not a valid variant of the resize_edge enum"/> | ||
651 | <entry name="invalid_parent" value="1" | ||
652 | summary="invalid parent toplevel"/> | ||
653 | <entry name="invalid_size" value="2" | ||
654 | summary="client provided an invalid min or max size"/> | ||
655 | </enum> | ||
656 | |||
657 | <request name="set_parent"> | ||
658 | <description summary="set the parent of this surface"> | ||
659 | Set the "parent" of this surface. This surface should be stacked | ||
660 | above the parent surface and all other ancestor surfaces. | ||
661 | |||
662 | Parent surfaces should be set on dialogs, toolboxes, or other | ||
663 | "auxiliary" surfaces, so that the parent is raised when the dialog | ||
664 | is raised. | ||
665 | |||
666 | Setting a null parent for a child surface unsets its parent. Setting | ||
667 | a null parent for a surface which currently has no parent is a no-op. | ||
668 | |||
669 | Only mapped surfaces can have child surfaces. Setting a parent which | ||
670 | is not mapped is equivalent to setting a null parent. If a surface | ||
671 | becomes unmapped, its children's parent is set to the parent of | ||
672 | the now-unmapped surface. If the now-unmapped surface has no parent, | ||
673 | its children's parent is unset. If the now-unmapped surface becomes | ||
674 | mapped again, its parent-child relationship is not restored. | ||
675 | |||
676 | The parent toplevel must not be one of the child toplevel's | ||
677 | descendants, and the parent must be different from the child toplevel, | ||
678 | otherwise the invalid_parent protocol error is raised. | ||
679 | </description> | ||
680 | <arg name="parent" type="object" interface="xdg_toplevel" allow-null="true"/> | ||
681 | </request> | ||
682 | |||
683 | <request name="set_title"> | ||
684 | <description summary="set surface title"> | ||
685 | Set a short title for the surface. | ||
686 | |||
687 | This string may be used to identify the surface in a task bar, | ||
688 | window list, or other user interface elements provided by the | ||
689 | compositor. | ||
690 | |||
691 | The string must be encoded in UTF-8. | ||
692 | </description> | ||
693 | <arg name="title" type="string"/> | ||
694 | </request> | ||
695 | |||
696 | <request name="set_app_id"> | ||
697 | <description summary="set application ID"> | ||
698 | Set an application identifier for the surface. | ||
699 | |||
700 | The app ID identifies the general class of applications to which | ||
701 | the surface belongs. The compositor can use this to group multiple | ||
702 | surfaces together, or to determine how to launch a new application. | ||
703 | |||
704 | For D-Bus activatable applications, the app ID is used as the D-Bus | ||
705 | service name. | ||
706 | |||
707 | The compositor shell will try to group application surfaces together | ||
708 | by their app ID. As a best practice, it is suggested to select app | ||
709 | ID's that match the basename of the application's .desktop file. | ||
710 | For example, "org.freedesktop.FooViewer" where the .desktop file is | ||
711 | "org.freedesktop.FooViewer.desktop". | ||
712 | |||
713 | Like other properties, a set_app_id request can be sent after the | ||
714 | xdg_toplevel has been mapped to update the property. | ||
715 | |||
716 | See the desktop-entry specification [0] for more details on | ||
717 | application identifiers and how they relate to well-known D-Bus | ||
718 | names and .desktop files. | ||
719 | |||
720 | [0] https://standards.freedesktop.org/desktop-entry-spec/ | ||
721 | </description> | ||
722 | <arg name="app_id" type="string"/> | ||
723 | </request> | ||
724 | |||
725 | <request name="show_window_menu"> | ||
726 | <description summary="show the window menu"> | ||
727 | Clients implementing client-side decorations might want to show | ||
728 | a context menu when right-clicking on the decorations, giving the | ||
729 | user a menu that they can use to maximize or minimize the window. | ||
730 | |||
731 | This request asks the compositor to pop up such a window menu at | ||
732 | the given position, relative to the local surface coordinates of | ||
733 | the parent surface. There are no guarantees as to what menu items | ||
734 | the window menu contains, or even if a window menu will be drawn | ||
735 | at all. | ||
736 | |||
737 | This request must be used in response to some sort of user action | ||
738 | like a button press, key press, or touch down event. | ||
739 | </description> | ||
740 | <arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/> | ||
741 | <arg name="serial" type="uint" summary="the serial of the user event"/> | ||
742 | <arg name="x" type="int" summary="the x position to pop up the window menu at"/> | ||
743 | <arg name="y" type="int" summary="the y position to pop up the window menu at"/> | ||
744 | </request> | ||
745 | |||
746 | <request name="move"> | ||
747 | <description summary="start an interactive move"> | ||
748 | Start an interactive, user-driven move of the surface. | ||
749 | |||
750 | This request must be used in response to some sort of user action | ||
751 | like a button press, key press, or touch down event. The passed | ||
752 | serial is used to determine the type of interactive move (touch, | ||
753 | pointer, etc). | ||
754 | |||
755 | The server may ignore move requests depending on the state of | ||
756 | the surface (e.g. fullscreen or maximized), or if the passed serial | ||
757 | is no longer valid. | ||
758 | |||
759 | If triggered, the surface will lose the focus of the device | ||
760 | (wl_pointer, wl_touch, etc) used for the move. It is up to the | ||
761 | compositor to visually indicate that the move is taking place, such as | ||
762 | updating a pointer cursor, during the move. There is no guarantee | ||
763 | that the device focus will return when the move is completed. | ||
764 | </description> | ||
765 | <arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/> | ||
766 | <arg name="serial" type="uint" summary="the serial of the user event"/> | ||
767 | </request> | ||
768 | |||
769 | <enum name="resize_edge"> | ||
770 | <description summary="edge values for resizing"> | ||
771 | These values are used to indicate which edge of a surface | ||
772 | is being dragged in a resize operation. | ||
773 | </description> | ||
774 | <entry name="none" value="0"/> | ||
775 | <entry name="top" value="1"/> | ||
776 | <entry name="bottom" value="2"/> | ||
777 | <entry name="left" value="4"/> | ||
778 | <entry name="top_left" value="5"/> | ||
779 | <entry name="bottom_left" value="6"/> | ||
780 | <entry name="right" value="8"/> | ||
781 | <entry name="top_right" value="9"/> | ||
782 | <entry name="bottom_right" value="10"/> | ||
783 | </enum> | ||
784 | |||
785 | <request name="resize"> | ||
786 | <description summary="start an interactive resize"> | ||
787 | Start a user-driven, interactive resize of the surface. | ||
788 | |||
789 | This request must be used in response to some sort of user action | ||
790 | like a button press, key press, or touch down event. The passed | ||
791 | serial is used to determine the type of interactive resize (touch, | ||
792 | pointer, etc). | ||
793 | |||
794 | The server may ignore resize requests depending on the state of | ||
795 | the surface (e.g. fullscreen or maximized). | ||
796 | |||
797 | If triggered, the client will receive configure events with the | ||
798 | "resize" state enum value and the expected sizes. See the "resize" | ||
799 | enum value for more details about what is required. The client | ||
800 | must also acknowledge configure events using "ack_configure". After | ||
801 | the resize is completed, the client will receive another "configure" | ||
802 | event without the resize state. | ||
803 | |||
804 | If triggered, the surface also will lose the focus of the device | ||
805 | (wl_pointer, wl_touch, etc) used for the resize. It is up to the | ||
806 | compositor to visually indicate that the resize is taking place, | ||
807 | such as updating a pointer cursor, during the resize. There is no | ||
808 | guarantee that the device focus will return when the resize is | ||
809 | completed. | ||
810 | |||
811 | The edges parameter specifies how the surface should be resized, and | ||
812 | is one of the values of the resize_edge enum. Values not matching | ||
813 | a variant of the enum will cause the invalid_resize_edge protocol error. | ||
814 | The compositor may use this information to update the surface position | ||
815 | for example when dragging the top left corner. The compositor may also | ||
816 | use this information to adapt its behavior, e.g. choose an appropriate | ||
817 | cursor image. | ||
818 | </description> | ||
819 | <arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/> | ||
820 | <arg name="serial" type="uint" summary="the serial of the user event"/> | ||
821 | <arg name="edges" type="uint" enum="resize_edge" summary="which edge or corner is being dragged"/> | ||
822 | </request> | ||
823 | |||
824 | <enum name="state"> | ||
825 | <description summary="types of state on the surface"> | ||
826 | The different state values used on the surface. This is designed for | ||
827 | state values like maximized, fullscreen. It is paired with the | ||
828 | configure event to ensure that both the client and the compositor | ||
829 | setting the state can be synchronized. | ||
830 | |||
831 | States set in this way are double-buffered. They will get applied on | ||
832 | the next commit. | ||
833 | </description> | ||
834 | <entry name="maximized" value="1" summary="the surface is maximized"> | ||
835 | <description summary="the surface is maximized"> | ||
836 | The surface is maximized. The window geometry specified in the configure | ||
837 | event must be obeyed by the client, or the xdg_wm_base.invalid_surface_state | ||
838 | error is raised. | ||
839 | |||
840 | The client should draw without shadow or other | ||
841 | decoration outside of the window geometry. | ||
842 | </description> | ||
843 | </entry> | ||
844 | <entry name="fullscreen" value="2" summary="the surface is fullscreen"> | ||
845 | <description summary="the surface is fullscreen"> | ||
846 | The surface is fullscreen. The window geometry specified in the | ||
847 | configure event is a maximum; the client cannot resize beyond it. For | ||
848 | a surface to cover the whole fullscreened area, the geometry | ||
849 | dimensions must be obeyed by the client. For more details, see | ||
850 | xdg_toplevel.set_fullscreen. | ||
851 | </description> | ||
852 | </entry> | ||
853 | <entry name="resizing" value="3" summary="the surface is being resized"> | ||
854 | <description summary="the surface is being resized"> | ||
855 | The surface is being resized. The window geometry specified in the | ||
856 | configure event is a maximum; the client cannot resize beyond it. | ||
857 | Clients that have aspect ratio or cell sizing configuration can use | ||
858 | a smaller size, however. | ||
859 | </description> | ||
860 | </entry> | ||
861 | <entry name="activated" value="4" summary="the surface is now activated"> | ||
862 | <description summary="the surface is now activated"> | ||
863 | Client window decorations should be painted as if the window is | ||
864 | active. Do not assume this means that the window actually has | ||
865 | keyboard or pointer focus. | ||
866 | </description> | ||
867 | </entry> | ||
868 | <entry name="tiled_left" value="5" since="2"> | ||
869 | <description summary="the surface’s left edge is tiled"> | ||
870 | The window is currently in a tiled layout and the left edge is | ||
871 | considered to be adjacent to another part of the tiling grid. | ||
872 | </description> | ||
873 | </entry> | ||
874 | <entry name="tiled_right" value="6" since="2"> | ||
875 | <description summary="the surface’s right edge is tiled"> | ||
876 | The window is currently in a tiled layout and the right edge is | ||
877 | considered to be adjacent to another part of the tiling grid. | ||
878 | </description> | ||
879 | </entry> | ||
880 | <entry name="tiled_top" value="7" since="2"> | ||
881 | <description summary="the surface’s top edge is tiled"> | ||
882 | The window is currently in a tiled layout and the top edge is | ||
883 | considered to be adjacent to another part of the tiling grid. | ||
884 | </description> | ||
885 | </entry> | ||
886 | <entry name="tiled_bottom" value="8" since="2"> | ||
887 | <description summary="the surface’s bottom edge is tiled"> | ||
888 | The window is currently in a tiled layout and the bottom edge is | ||
889 | considered to be adjacent to another part of the tiling grid. | ||
890 | </description> | ||
891 | </entry> | ||
892 | <entry name="suspended" value="9" since="6"> | ||
893 | <description summary="surface repaint is suspended"> | ||
894 | The surface is currently not ordinarily being repainted; for | ||
895 | example because its content is occluded by another window, or its | ||
896 | outputs are switched off due to screen locking. | ||
897 | </description> | ||
898 | </entry> | ||
899 | </enum> | ||
900 | |||
901 | <request name="set_max_size"> | ||
902 | <description summary="set the maximum size"> | ||
903 | Set a maximum size for the window. | ||
904 | |||
905 | The client can specify a maximum size so that the compositor does | ||
906 | not try to configure the window beyond this size. | ||
907 | |||
908 | The width and height arguments are in window geometry coordinates. | ||
909 | See xdg_surface.set_window_geometry. | ||
910 | |||
911 | Values set in this way are double-buffered. They will get applied | ||
912 | on the next commit. | ||
913 | |||
914 | The compositor can use this information to allow or disallow | ||
915 | different states like maximize or fullscreen and draw accurate | ||
916 | animations. | ||
917 | |||
918 | Similarly, a tiling window manager may use this information to | ||
919 | place and resize client windows in a more effective way. | ||
920 | |||
921 | The client should not rely on the compositor to obey the maximum | ||
922 | size. The compositor may decide to ignore the values set by the | ||
923 | client and request a larger size. | ||
924 | |||
925 | If never set, or a value of zero in the request, means that the | ||
926 | client has no expected maximum size in the given dimension. | ||
927 | As a result, a client wishing to reset the maximum size | ||
928 | to an unspecified state can use zero for width and height in the | ||
929 | request. | ||
930 | |||
931 | Requesting a maximum size to be smaller than the minimum size of | ||
932 | a surface is illegal and will result in an invalid_size error. | ||
933 | |||
934 | The width and height must be greater than or equal to zero. Using | ||
935 | strictly negative values for width or height will result in a | ||
936 | invalid_size error. | ||
937 | </description> | ||
938 | <arg name="width" type="int"/> | ||
939 | <arg name="height" type="int"/> | ||
940 | </request> | ||
941 | |||
942 | <request name="set_min_size"> | ||
943 | <description summary="set the minimum size"> | ||
944 | Set a minimum size for the window. | ||
945 | |||
946 | The client can specify a minimum size so that the compositor does | ||
947 | not try to configure the window below this size. | ||
948 | |||
949 | The width and height arguments are in window geometry coordinates. | ||
950 | See xdg_surface.set_window_geometry. | ||
951 | |||
952 | Values set in this way are double-buffered. They will get applied | ||
953 | on the next commit. | ||
954 | |||
955 | The compositor can use this information to allow or disallow | ||
956 | different states like maximize or fullscreen and draw accurate | ||
957 | animations. | ||
958 | |||
959 | Similarly, a tiling window manager may use this information to | ||
960 | place and resize client windows in a more effective way. | ||
961 | |||
962 | The client should not rely on the compositor to obey the minimum | ||
963 | size. The compositor may decide to ignore the values set by the | ||
964 | client and request a smaller size. | ||
965 | |||
966 | If never set, or a value of zero in the request, means that the | ||
967 | client has no expected minimum size in the given dimension. | ||
968 | As a result, a client wishing to reset the minimum size | ||
969 | to an unspecified state can use zero for width and height in the | ||
970 | request. | ||
971 | |||
972 | Requesting a minimum size to be larger than the maximum size of | ||
973 | a surface is illegal and will result in an invalid_size error. | ||
974 | |||
975 | The width and height must be greater than or equal to zero. Using | ||
976 | strictly negative values for width and height will result in a | ||
977 | invalid_size error. | ||
978 | </description> | ||
979 | <arg name="width" type="int"/> | ||
980 | <arg name="height" type="int"/> | ||
981 | </request> | ||
982 | |||
983 | <request name="set_maximized"> | ||
984 | <description summary="maximize the window"> | ||
985 | Maximize the surface. | ||
986 | |||
987 | After requesting that the surface should be maximized, the compositor | ||
988 | will respond by emitting a configure event. Whether this configure | ||
989 | actually sets the window maximized is subject to compositor policies. | ||
990 | The client must then update its content, drawing in the configured | ||
991 | state. The client must also acknowledge the configure when committing | ||
992 | the new content (see ack_configure). | ||
993 | |||
994 | It is up to the compositor to decide how and where to maximize the | ||
995 | surface, for example which output and what region of the screen should | ||
996 | be used. | ||
997 | |||
998 | If the surface was already maximized, the compositor will still emit | ||
999 | a configure event with the "maximized" state. | ||
1000 | |||
1001 | If the surface is in a fullscreen state, this request has no direct | ||
1002 | effect. It may alter the state the surface is returned to when | ||
1003 | unmaximized unless overridden by the compositor. | ||
1004 | </description> | ||
1005 | </request> | ||
1006 | |||
1007 | <request name="unset_maximized"> | ||
1008 | <description summary="unmaximize the window"> | ||
1009 | Unmaximize the surface. | ||
1010 | |||
1011 | After requesting that the surface should be unmaximized, the compositor | ||
1012 | will respond by emitting a configure event. Whether this actually | ||
1013 | un-maximizes the window is subject to compositor policies. | ||
1014 | If available and applicable, the compositor will include the window | ||
1015 | geometry dimensions the window had prior to being maximized in the | ||
1016 | configure event. The client must then update its content, drawing it in | ||
1017 | the configured state. The client must also acknowledge the configure | ||
1018 | when committing the new content (see ack_configure). | ||
1019 | |||
1020 | It is up to the compositor to position the surface after it was | ||
1021 | unmaximized; usually the position the surface had before maximizing, if | ||
1022 | applicable. | ||
1023 | |||
1024 | If the surface was already not maximized, the compositor will still | ||
1025 | emit a configure event without the "maximized" state. | ||
1026 | |||
1027 | If the surface is in a fullscreen state, this request has no direct | ||
1028 | effect. It may alter the state the surface is returned to when | ||
1029 | unmaximized unless overridden by the compositor. | ||
1030 | </description> | ||
1031 | </request> | ||
1032 | |||
1033 | <request name="set_fullscreen"> | ||
1034 | <description summary="set the window as fullscreen on an output"> | ||
1035 | Make the surface fullscreen. | ||
1036 | |||
1037 | After requesting that the surface should be fullscreened, the | ||
1038 | compositor will respond by emitting a configure event. Whether the | ||
1039 | client is actually put into a fullscreen state is subject to compositor | ||
1040 | policies. The client must also acknowledge the configure when | ||
1041 | committing the new content (see ack_configure). | ||
1042 | |||
1043 | The output passed by the request indicates the client's preference as | ||
1044 | to which display it should be set fullscreen on. If this value is NULL, | ||
1045 | it's up to the compositor to choose which display will be used to map | ||
1046 | this surface. | ||
1047 | |||
1048 | If the surface doesn't cover the whole output, the compositor will | ||
1049 | position the surface in the center of the output and compensate with | ||
1050 | with border fill covering the rest of the output. The content of the | ||
1051 | border fill is undefined, but should be assumed to be in some way that | ||
1052 | attempts to blend into the surrounding area (e.g. solid black). | ||
1053 | |||
1054 | If the fullscreened surface is not opaque, the compositor must make | ||
1055 | sure that other screen content not part of the same surface tree (made | ||
1056 | up of subsurfaces, popups or similarly coupled surfaces) are not | ||
1057 | visible below the fullscreened surface. | ||
1058 | </description> | ||
1059 | <arg name="output" type="object" interface="wl_output" allow-null="true"/> | ||
1060 | </request> | ||
1061 | |||
1062 | <request name="unset_fullscreen"> | ||
1063 | <description summary="unset the window as fullscreen"> | ||
1064 | Make the surface no longer fullscreen. | ||
1065 | |||
1066 | After requesting that the surface should be unfullscreened, the | ||
1067 | compositor will respond by emitting a configure event. | ||
1068 | Whether this actually removes the fullscreen state of the client is | ||
1069 | subject to compositor policies. | ||
1070 | |||
1071 | Making a surface unfullscreen sets states for the surface based on the following: | ||
1072 | * the state(s) it may have had before becoming fullscreen | ||
1073 | * any state(s) decided by the compositor | ||
1074 | * any state(s) requested by the client while the surface was fullscreen | ||
1075 | |||
1076 | The compositor may include the previous window geometry dimensions in | ||
1077 | the configure event, if applicable. | ||
1078 | |||
1079 | The client must also acknowledge the configure when committing the new | ||
1080 | content (see ack_configure). | ||
1081 | </description> | ||
1082 | </request> | ||
1083 | |||
1084 | <request name="set_minimized"> | ||
1085 | <description summary="set the window as minimized"> | ||
1086 | Request that the compositor minimize your surface. There is no | ||
1087 | way to know if the surface is currently minimized, nor is there | ||
1088 | any way to unset minimization on this surface. | ||
1089 | |||
1090 | If you are looking to throttle redrawing when minimized, please | ||
1091 | instead use the wl_surface.frame event for this, as this will | ||
1092 | also work with live previews on windows in Alt-Tab, Expose or | ||
1093 | similar compositor features. | ||
1094 | </description> | ||
1095 | </request> | ||
1096 | |||
1097 | <event name="configure"> | ||
1098 | <description summary="suggest a surface change"> | ||
1099 | This configure event asks the client to resize its toplevel surface or | ||
1100 | to change its state. The configured state should not be applied | ||
1101 | immediately. See xdg_surface.configure for details. | ||
1102 | |||
1103 | The width and height arguments specify a hint to the window | ||
1104 | about how its surface should be resized in window geometry | ||
1105 | coordinates. See set_window_geometry. | ||
1106 | |||
1107 | If the width or height arguments are zero, it means the client | ||
1108 | should decide its own window dimension. This may happen when the | ||
1109 | compositor needs to configure the state of the surface but doesn't | ||
1110 | have any information about any previous or expected dimension. | ||
1111 | |||
1112 | The states listed in the event specify how the width/height | ||
1113 | arguments should be interpreted, and possibly how it should be | ||
1114 | drawn. | ||
1115 | |||
1116 | Clients must send an ack_configure in response to this event. See | ||
1117 | xdg_surface.configure and xdg_surface.ack_configure for details. | ||
1118 | </description> | ||
1119 | <arg name="width" type="int"/> | ||
1120 | <arg name="height" type="int"/> | ||
1121 | <arg name="states" type="array"/> | ||
1122 | </event> | ||
1123 | |||
1124 | <event name="close"> | ||
1125 | <description summary="surface wants to be closed"> | ||
1126 | The close event is sent by the compositor when the user | ||
1127 | wants the surface to be closed. This should be equivalent to | ||
1128 | the user clicking the close button in client-side decorations, | ||
1129 | if your application has any. | ||
1130 | |||
1131 | This is only a request that the user intends to close the | ||
1132 | window. The client may choose to ignore this request, or show | ||
1133 | a dialog to ask the user to save their data, etc. | ||
1134 | </description> | ||
1135 | </event> | ||
1136 | |||
1137 | <!-- Version 4 additions --> | ||
1138 | |||
1139 | <event name="configure_bounds" since="4"> | ||
1140 | <description summary="recommended window geometry bounds"> | ||
1141 | The configure_bounds event may be sent prior to a xdg_toplevel.configure | ||
1142 | event to communicate the bounds a window geometry size is recommended | ||
1143 | to constrain to. | ||
1144 | |||
1145 | The passed width and height are in surface coordinate space. If width | ||
1146 | and height are 0, it means bounds is unknown and equivalent to as if no | ||
1147 | configure_bounds event was ever sent for this surface. | ||
1148 | |||
1149 | The bounds can for example correspond to the size of a monitor excluding | ||
1150 | any panels or other shell components, so that a surface isn't created in | ||
1151 | a way that it cannot fit. | ||
1152 | |||
1153 | The bounds may change at any point, and in such a case, a new | ||
1154 | xdg_toplevel.configure_bounds will be sent, followed by | ||
1155 | xdg_toplevel.configure and xdg_surface.configure. | ||
1156 | </description> | ||
1157 | <arg name="width" type="int"/> | ||
1158 | <arg name="height" type="int"/> | ||
1159 | </event> | ||
1160 | |||
1161 | <!-- Version 5 additions --> | ||
1162 | |||
1163 | <enum name="wm_capabilities" since="5"> | ||
1164 | <entry name="window_menu" value="1" summary="show_window_menu is available"/> | ||
1165 | <entry name="maximize" value="2" summary="set_maximized and unset_maximized are available"/> | ||
1166 | <entry name="fullscreen" value="3" summary="set_fullscreen and unset_fullscreen are available"/> | ||
1167 | <entry name="minimize" value="4" summary="set_minimized is available"/> | ||
1168 | </enum> | ||
1169 | |||
1170 | <event name="wm_capabilities" since="5"> | ||
1171 | <description summary="compositor capabilities"> | ||
1172 | This event advertises the capabilities supported by the compositor. If | ||
1173 | a capability isn't supported, clients should hide or disable the UI | ||
1174 | elements that expose this functionality. For instance, if the | ||
1175 | compositor doesn't advertise support for minimized toplevels, a button | ||
1176 | triggering the set_minimized request should not be displayed. | ||
1177 | |||
1178 | The compositor will ignore requests it doesn't support. For instance, | ||
1179 | a compositor which doesn't advertise support for minimized will ignore | ||
1180 | set_minimized requests. | ||
1181 | |||
1182 | Compositors must send this event once before the first | ||
1183 | xdg_surface.configure event. When the capabilities change, compositors | ||
1184 | must send this event again and then send an xdg_surface.configure | ||
1185 | event. | ||
1186 | |||
1187 | The configured state should not be applied immediately. See | ||
1188 | xdg_surface.configure for details. | ||
1189 | |||
1190 | The capabilities are sent as an array of 32-bit unsigned integers in | ||
1191 | native endianness. | ||
1192 | </description> | ||
1193 | <arg name="capabilities" type="array" summary="array of 32-bit capabilities"/> | ||
1194 | </event> | ||
1195 | </interface> | ||
1196 | |||
1197 | <interface name="xdg_popup" version="6"> | ||
1198 | <description summary="short-lived, popup surfaces for menus"> | ||
1199 | A popup surface is a short-lived, temporary surface. It can be used to | ||
1200 | implement for example menus, popovers, tooltips and other similar user | ||
1201 | interface concepts. | ||
1202 | |||
1203 | A popup can be made to take an explicit grab. See xdg_popup.grab for | ||
1204 | details. | ||
1205 | |||
1206 | When the popup is dismissed, a popup_done event will be sent out, and at | ||
1207 | the same time the surface will be unmapped. See the xdg_popup.popup_done | ||
1208 | event for details. | ||
1209 | |||
1210 | Explicitly destroying the xdg_popup object will also dismiss the popup and | ||
1211 | unmap the surface. Clients that want to dismiss the popup when another | ||
1212 | surface of their own is clicked should dismiss the popup using the destroy | ||
1213 | request. | ||
1214 | |||
1215 | A newly created xdg_popup will be stacked on top of all previously created | ||
1216 | xdg_popup surfaces associated with the same xdg_toplevel. | ||
1217 | |||
1218 | The parent of an xdg_popup must be mapped (see the xdg_surface | ||
1219 | description) before the xdg_popup itself. | ||
1220 | |||
1221 | The client must call wl_surface.commit on the corresponding wl_surface | ||
1222 | for the xdg_popup state to take effect. | ||
1223 | </description> | ||
1224 | |||
1225 | <enum name="error"> | ||
1226 | <entry name="invalid_grab" value="0" | ||
1227 | summary="tried to grab after being mapped"/> | ||
1228 | </enum> | ||
1229 | |||
1230 | <request name="destroy" type="destructor"> | ||
1231 | <description summary="remove xdg_popup interface"> | ||
1232 | This destroys the popup. Explicitly destroying the xdg_popup | ||
1233 | object will also dismiss the popup, and unmap the surface. | ||
1234 | |||
1235 | If this xdg_popup is not the "topmost" popup, the | ||
1236 | xdg_wm_base.not_the_topmost_popup protocol error will be sent. | ||
1237 | </description> | ||
1238 | </request> | ||
1239 | |||
1240 | <request name="grab"> | ||
1241 | <description summary="make the popup take an explicit grab"> | ||
1242 | This request makes the created popup take an explicit grab. An explicit | ||
1243 | grab will be dismissed when the user dismisses the popup, or when the | ||
1244 | client destroys the xdg_popup. This can be done by the user clicking | ||
1245 | outside the surface, using the keyboard, or even locking the screen | ||
1246 | through closing the lid or a timeout. | ||
1247 | |||
1248 | If the compositor denies the grab, the popup will be immediately | ||
1249 | dismissed. | ||
1250 | |||
1251 | This request must be used in response to some sort of user action like a | ||
1252 | button press, key press, or touch down event. The serial number of the | ||
1253 | event should be passed as 'serial'. | ||
1254 | |||
1255 | The parent of a grabbing popup must either be an xdg_toplevel surface or | ||
1256 | another xdg_popup with an explicit grab. If the parent is another | ||
1257 | xdg_popup it means that the popups are nested, with this popup now being | ||
1258 | the topmost popup. | ||
1259 | |||
1260 | Nested popups must be destroyed in the reverse order they were created | ||
1261 | in, e.g. the only popup you are allowed to destroy at all times is the | ||
1262 | topmost one. | ||
1263 | |||
1264 | When compositors choose to dismiss a popup, they may dismiss every | ||
1265 | nested grabbing popup as well. When a compositor dismisses popups, it | ||
1266 | will follow the same dismissing order as required from the client. | ||
1267 | |||
1268 | If the topmost grabbing popup is destroyed, the grab will be returned to | ||
1269 | the parent of the popup, if that parent previously had an explicit grab. | ||
1270 | |||
1271 | If the parent is a grabbing popup which has already been dismissed, this | ||
1272 | popup will be immediately dismissed. If the parent is a popup that did | ||
1273 | not take an explicit grab, an error will be raised. | ||
1274 | |||
1275 | During a popup grab, the client owning the grab will receive pointer | ||
1276 | and touch events for all their surfaces as normal (similar to an | ||
1277 | "owner-events" grab in X11 parlance), while the top most grabbing popup | ||
1278 | will always have keyboard focus. | ||
1279 | </description> | ||
1280 | <arg name="seat" type="object" interface="wl_seat" | ||
1281 | summary="the wl_seat of the user event"/> | ||
1282 | <arg name="serial" type="uint" summary="the serial of the user event"/> | ||
1283 | </request> | ||
1284 | |||
1285 | <event name="configure"> | ||
1286 | <description summary="configure the popup surface"> | ||
1287 | This event asks the popup surface to configure itself given the | ||
1288 | configuration. The configured state should not be applied immediately. | ||
1289 | See xdg_surface.configure for details. | ||
1290 | |||
1291 | The x and y arguments represent the position the popup was placed at | ||
1292 | given the xdg_positioner rule, relative to the upper left corner of the | ||
1293 | window geometry of the parent surface. | ||
1294 | |||
1295 | For version 2 or older, the configure event for an xdg_popup is only | ||
1296 | ever sent once for the initial configuration. Starting with version 3, | ||
1297 | it may be sent again if the popup is setup with an xdg_positioner with | ||
1298 | set_reactive requested, or in response to xdg_popup.reposition requests. | ||
1299 | </description> | ||
1300 | <arg name="x" type="int" | ||
1301 | summary="x position relative to parent surface window geometry"/> | ||
1302 | <arg name="y" type="int" | ||
1303 | summary="y position relative to parent surface window geometry"/> | ||
1304 | <arg name="width" type="int" summary="window geometry width"/> | ||
1305 | <arg name="height" type="int" summary="window geometry height"/> | ||
1306 | </event> | ||
1307 | |||
1308 | <event name="popup_done"> | ||
1309 | <description summary="popup interaction is done"> | ||
1310 | The popup_done event is sent out when a popup is dismissed by the | ||
1311 | compositor. The client should destroy the xdg_popup object at this | ||
1312 | point. | ||
1313 | </description> | ||
1314 | </event> | ||
1315 | |||
1316 | <!-- Version 3 additions --> | ||
1317 | |||
1318 | <request name="reposition" since="3"> | ||
1319 | <description summary="recalculate the popup's location"> | ||
1320 | Reposition an already-mapped popup. The popup will be placed given the | ||
1321 | details in the passed xdg_positioner object, and a | ||
1322 | xdg_popup.repositioned followed by xdg_popup.configure and | ||
1323 | xdg_surface.configure will be emitted in response. Any parameters set | ||
1324 | by the previous positioner will be discarded. | ||
1325 | |||
1326 | The passed token will be sent in the corresponding | ||
1327 | xdg_popup.repositioned event. The new popup position will not take | ||
1328 | effect until the corresponding configure event is acknowledged by the | ||
1329 | client. See xdg_popup.repositioned for details. The token itself is | ||
1330 | opaque, and has no other special meaning. | ||
1331 | |||
1332 | If multiple reposition requests are sent, the compositor may skip all | ||
1333 | but the last one. | ||
1334 | |||
1335 | If the popup is repositioned in response to a configure event for its | ||
1336 | parent, the client should send an xdg_positioner.set_parent_configure | ||
1337 | and possibly an xdg_positioner.set_parent_size request to allow the | ||
1338 | compositor to properly constrain the popup. | ||
1339 | |||
1340 | If the popup is repositioned together with a parent that is being | ||
1341 | resized, but not in response to a configure event, the client should | ||
1342 | send an xdg_positioner.set_parent_size request. | ||
1343 | </description> | ||
1344 | <arg name="positioner" type="object" interface="xdg_positioner"/> | ||
1345 | <arg name="token" type="uint" summary="reposition request token"/> | ||
1346 | </request> | ||
1347 | |||
1348 | <event name="repositioned" since="3"> | ||
1349 | <description summary="signal the completion of a repositioned request"> | ||
1350 | The repositioned event is sent as part of a popup configuration | ||
1351 | sequence, together with xdg_popup.configure and lastly | ||
1352 | xdg_surface.configure to notify the completion of a reposition request. | ||
1353 | |||
1354 | The repositioned event is to notify about the completion of a | ||
1355 | xdg_popup.reposition request. The token argument is the token passed | ||
1356 | in the xdg_popup.reposition request. | ||
1357 | |||
1358 | Immediately after this event is emitted, xdg_popup.configure and | ||
1359 | xdg_surface.configure will be sent with the updated size and position, | ||
1360 | as well as a new configure serial. | ||
1361 | |||
1362 | The client should optionally update the content of the popup, but must | ||
1363 | acknowledge the new popup configuration for the new position to take | ||
1364 | effect. See xdg_surface.ack_configure for details. | ||
1365 | </description> | ||
1366 | <arg name="token" type="uint" summary="reposition request token"/> | ||
1367 | </event> | ||
1368 | |||
1369 | </interface> | ||
1370 | </protocol> | ||