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