xdg-shell: Clarify the meaning of app ID and give example
[platform/upstream/weston.git] / protocol / xdg-shell.xml
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
10     Permission to use, copy, modify, distribute, and sell this
11     software and its documentation for any purpose is hereby granted
12     without fee, provided that the above copyright notice appear in
13     all copies and that both that copyright notice and this permission
14     notice appear in supporting documentation, and that the name of
15     the copyright holders not be used in advertising or publicity
16     pertaining to distribution of the software without specific,
17     written prior permission.  The copyright holders make no
18     representations about the suitability of this software for any
19     purpose.  It is provided "as is" without express or implied
20     warranty.
21
22     THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
23     SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
24     FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
25     SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
26     WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
27     AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
28     ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
29     THIS SOFTWARE.
30   </copyright>
31
32   <interface name="xdg_shell" version="1">
33     <description summary="create desktop-style surfaces">
34       xdg_shell allows clients to turn a wl_surface into a "real window"
35       which can be dragged, resized, stacked, and moved around by the
36       user. Everything about this interface is suited towards traditional
37       desktop environments.
38     </description>
39
40     <enum name="version">
41       <description summary="latest protocol version">
42         The 'current' member of this enum gives the version of the
43         protocol.  Implementations can compare this to the version
44         they implement using static_assert to ensure the protocol and
45         implementation versions match.
46       </description>
47       <entry name="current" value="5" summary="Always the latest version"/>
48     </enum>
49
50     <enum name="error">
51       <entry name="role" value="0" summary="given wl_surface has another role"/>
52       <entry name="defunct_surfaces" value="1" summary="xdg_shell was destroyed before children"/>
53       <entry name="not_the_topmost_popup" value="2" summary="the client tried to map or destroy a non-topmost popup"/>
54       <entry name="invalid_popup_parent" value="3" summary="the client specified an invalid popup parent surface"/>
55     </enum>
56
57     <request name="destroy" type="destructor">
58       <description summary="destroy xdg_shell">
59         Destroy this xdg_shell object.
60
61         Destroying a bound xdg_shell object while there are surfaces
62         still alive created by this xdg_shell object instance is illegal
63         and will result in a protocol error.
64       </description>
65     </request>
66
67     <request name="use_unstable_version">
68       <description summary="enable use of this unstable version">
69         Negotiate the unstable version of the interface.  This
70         mechanism is in place to ensure client and server agree on the
71         unstable versions of the protocol that they speak or exit
72         cleanly if they don't agree.  This request will go away once
73         the xdg-shell protocol is stable.
74       </description>
75       <arg name="version" type="int"/>
76     </request>
77
78     <request name="get_xdg_surface">
79       <description summary="create a shell surface from a surface">
80         This creates an xdg_surface for the given surface and gives it the
81         xdg_surface role. See the documentation of xdg_surface for more details.
82       </description>
83       <arg name="id" type="new_id" interface="xdg_surface"/>
84       <arg name="surface" type="object" interface="wl_surface"/>
85     </request>
86
87     <request name="get_xdg_popup">
88       <description summary="create a popup for a surface">
89         This creates an xdg_popup for the given surface and gives it the
90         xdg_popup role. See the documentation of xdg_popup for more details.
91
92         This request must be used in response to some sort of user action
93         like a button press, key press, or touch down event.
94       </description>
95       <arg name="id" type="new_id" interface="xdg_popup"/>
96       <arg name="surface" type="object" interface="wl_surface"/>
97       <arg name="parent" type="object" interface="wl_surface"/>
98       <arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/>
99       <arg name="serial" type="uint" summary="the serial of the user event"/>
100       <arg name="x" type="int"/>
101       <arg name="y" type="int"/>
102     </request>
103
104     <event name="ping">
105       <description summary="check if the client is alive">
106         The ping event asks the client if it's still alive. Pass the
107         serial specified in the event back to the compositor by sending
108         a "pong" request back with the specified serial.
109
110         Compositors can use this to determine if the client is still
111         alive. It's unspecified what will happen if the client doesn't
112         respond to the ping request, or in what timeframe. Clients should
113         try to respond in a reasonable amount of time.
114       </description>
115       <arg name="serial" type="uint" summary="pass this to the pong request"/>
116     </event>
117
118     <request name="pong">
119       <description summary="respond to a ping event">
120         A client must respond to a ping event with a pong request or
121         the client may be deemed unresponsive.
122       </description>
123       <arg name="serial" type="uint" summary="serial of the ping event"/>
124     </request>
125   </interface>
126
127   <interface name="xdg_surface" version="1">
128     <description summary="A desktop window">
129       An interface that may be implemented by a wl_surface, for
130       implementations that provide a desktop-style user interface.
131
132       It provides requests to treat surfaces like windows, allowing to set
133       properties like maximized, fullscreen, minimized, and to move and resize
134       them, and associate metadata like title and app id.
135
136       The client must call wl_surface.commit on the corresponding wl_surface
137       for the xdg_surface state to take effect. Prior to committing the new
138       state, it can set up initial configuration, such as maximizing or setting
139       a window geometry.
140
141       Even without attaching a buffer the compositor must respond to initial
142       committed configuration, for instance sending a configure event with
143       expected window geometry if the client maximized its surface during
144       initialization.
145
146       For a surface to be mapped by the compositor the client must have
147       committed both an xdg_surface state and a buffer.
148     </description>
149
150     <request name="destroy" type="destructor">
151       <description summary="Destroy the xdg_surface">
152         Unmap and destroy the window. The window will be effectively
153         hidden from the user's point of view, and all state like
154         maximization, fullscreen, and so on, will be lost.
155       </description>
156     </request>
157
158     <request name="set_parent">
159       <description summary="set the parent of this surface">
160         Set the "parent" of this surface. This window should be stacked
161         above a parent. The parent surface must be mapped as long as this
162         surface is mapped.
163
164         Parent windows should be set on dialogs, toolboxes, or other
165         "auxiliary" surfaces, so that the parent is raised when the dialog
166         is raised.
167       </description>
168       <arg name="parent" type="object" interface="xdg_surface" allow-null="true"/>
169     </request>
170
171     <request name="set_title">
172       <description summary="set surface title">
173         Set a short title for the surface.
174
175         This string may be used to identify the surface in a task bar,
176         window list, or other user interface elements provided by the
177         compositor.
178
179         The string must be encoded in UTF-8.
180       </description>
181       <arg name="title" type="string"/>
182     </request>
183
184     <request name="set_app_id">
185       <description summary="set application ID">
186         Set an application identifier for the surface.
187
188         The app ID identifies the general class of applications to which
189         the surface belongs. The compositor can use this to group multiple
190         surfaces together, or to determine how to launch a new application.
191
192         For D-Bus activatable applications, the app ID is used as the D-Bus
193         service name.
194
195         The compositor shell will try to group application surfaces together
196         by their app ID.  As a best practice, it is suggested to select app
197         ID's that match the basename of the application's .desktop file.
198         For example, "org.freedesktop.FooViewer" where the .desktop file is
199         "org.freedesktop.FooViewer.desktop".
200
201         See the desktop-entry specification [0] for more details on
202         application identifiers and how they relate to well-known D-Bus
203         names and .desktop files.
204
205         [0] http://standards.freedesktop.org/desktop-entry-spec/
206       </description>
207       <arg name="app_id" type="string"/>
208     </request>
209
210     <request name="show_window_menu">
211       <description summary="show the window menu">
212         Clients implementing client-side decorations might want to show
213         a context menu when right-clicking on the decorations, giving the
214         user a menu that they can use to maximize or minimize the window.
215
216         This request asks the compositor to pop up such a window menu at
217         the given position, relative to the local surface coordinates of
218         the parent surface. There are no guarantees as to what menu items
219         the window menu contains.
220
221         This request must be used in response to some sort of user action
222         like a button press, key press, or touch down event.
223       </description>
224
225       <arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/>
226       <arg name="serial" type="uint" summary="the serial of the user event"/>
227       <arg name="x" type="int" summary="the x position to pop up the window menu at"/>
228       <arg name="y" type="int" summary="the y position to pop up the window menu at"/>
229     </request>
230
231     <request name="move">
232       <description summary="start an interactive move">
233         Start an interactive, user-driven move of the surface.
234
235         This request must be used in response to some sort of user action
236         like a button press, key press, or touch down event.
237
238         The server may ignore move requests depending on the state of
239         the surface (e.g. fullscreen or maximized).
240       </description>
241       <arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/>
242       <arg name="serial" type="uint" summary="the serial of the user event"/>
243     </request>
244
245     <enum name="resize_edge">
246       <description summary="edge values for resizing">
247         These values are used to indicate which edge of a surface
248         is being dragged in a resize operation. The server may
249         use this information to adapt its behavior, e.g. choose
250         an appropriate cursor image.
251       </description>
252       <entry name="none" value="0"/>
253       <entry name="top" value="1"/>
254       <entry name="bottom" value="2"/>
255       <entry name="left" value="4"/>
256       <entry name="top_left" value="5"/>
257       <entry name="bottom_left" value="6"/>
258       <entry name="right" value="8"/>
259       <entry name="top_right" value="9"/>
260       <entry name="bottom_right" value="10"/>
261     </enum>
262
263     <request name="resize">
264       <description summary="start an interactive resize">
265         Start a user-driven, interactive resize of the surface.
266
267         This request must be used in response to some sort of user action
268         like a button press, key press, or touch down event.
269
270         The server may ignore resize requests depending on the state of
271         the surface (e.g. fullscreen or maximized).
272       </description>
273       <arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/>
274       <arg name="serial" type="uint" summary="the serial of the user event"/>
275       <arg name="edges" type="uint" summary="which edge or corner is being dragged"/>
276     </request>
277
278     <enum name="state">
279       <description summary="types of state on the surface">
280         The different state values used on the surface. This is designed for
281         state values like maximized, fullscreen. It is paired with the
282         configure event to ensure that both the client and the compositor
283         setting the state can be synchronized.
284
285         States set in this way are double-buffered. They will get applied on
286         the next commit.
287
288         Desktop environments may extend this enum by taking up a range of
289         values and documenting the range they chose in this description.
290         They are not required to document the values for the range that they
291         chose. Ideally, any good extensions from a desktop environment should
292         make its way into standardization into this enum.
293
294         The current reserved ranges are:
295
296         0x0000 - 0x0FFF: xdg-shell core values, documented below.
297         0x1000 - 0x1FFF: GNOME
298       </description>
299       <entry name="maximized" value="1" summary="the surface is maximized">
300         The surface is maximized. The window geometry specified in the configure
301         event must be obeyed by the client.
302       </entry>
303       <entry name="fullscreen" value="2" summary="the surface is fullscreen">
304         The surface is fullscreen. The window geometry specified in the configure
305         event must be obeyed by the client.
306       </entry>
307       <entry name="resizing" value="3">
308         The surface is being resized. The window geometry specified in the
309         configure event is a maximum; the client cannot resize beyond it.
310         Clients that have aspect ratio or cell sizing configuration can use
311         a smaller size, however.
312       </entry>
313       <entry name="activated" value="4">
314         Client window decorations should be painted as if the window is
315         active. Do not assume this means that the window actually has
316         keyboard or pointer focus.
317       </entry>
318     </enum>
319
320     <event name="configure">
321       <description summary="suggest a surface change">
322         The configure event asks the client to resize its surface or to
323         change its state.
324
325         The width and height arguments specify a hint to the window
326         about how its surface should be resized in window geometry
327         coordinates. See set_window_geometry.
328
329         If the width or height arguments are zero, it means the client
330         should decide its own window dimension. This may happen when the
331         compositor need to configure the state of the surface but doesn't
332         have any information about any previous or expected dimension.
333
334         The states listed in the event specify how the width/height
335         arguments should be interpreted, and possibly how it should be
336         drawn.
337
338         Clients should arrange their surface for the new size and
339         states, and then send a ack_configure request with the serial
340         sent in this configure event at some point before committing
341         the new surface.
342
343         If the client receives multiple configure events before it
344         can respond to one, it is free to discard all but the last
345         event it received.
346       </description>
347
348       <arg name="width" type="int"/>
349       <arg name="height" type="int"/>
350       <arg name="states" type="array"/>
351       <arg name="serial" type="uint"/>
352     </event>
353
354     <request name="ack_configure">
355       <description summary="ack a configure event">
356         When a configure event is received, if a client commits the
357         surface in response to the configure event, then the client
358         must make a ack_configure request before the commit request,
359         passing along the serial of the configure event.
360
361         For instance, the compositor might use this information to move
362         a surface to the top left only when the client has drawn itself
363         for the maximized or fullscreen state.
364
365         If the client receives multiple configure events before it
366         can respond to one, it only has to ack the last configure event.
367       </description>
368       <arg name="serial" type="uint" summary="the serial from the configure event"/>
369     </request>
370
371     <request name="set_window_geometry">
372       <description summary="set the new window geometry">
373         The window geometry of a window is its "visible bounds" from the
374         user's perspective. Client-side decorations often have invisible
375         portions like drop-shadows which should be ignored for the
376         purposes of aligning, placing and constraining windows.
377
378         The window geometry is double buffered, and will be applied at the
379         time wl_surface.commit of the corresponding wl_surface is called.
380
381         Once the window geometry of the surface is set once, it is not
382         possible to unset it, and it will remain the same until
383         set_window_geometry is called again, even if a new subsurface or
384         buffer is attached.
385
386         If never set, the value is the full bounds of the surface,
387         including any subsurfaces. This updates dynamically on every
388         commit. This unset mode is meant for extremely simple clients.
389
390         If responding to a configure event, the window geometry in here
391         must respect the sizing negotiations specified by the states in
392         the configure event.
393
394         The arguments are given in the surface local coordinate space of
395         the wl_surface associated with this xdg_surface.
396
397         The width and height must be greater than zero.
398       </description>
399       <arg name="x" type="int"/>
400       <arg name="y" type="int"/>
401       <arg name="width" type="int"/>
402       <arg name="height" type="int"/>
403     </request>
404
405     <request name="set_maximized" />
406     <request name="unset_maximized" />
407
408     <request name="set_fullscreen">
409       <description summary="set the window as fullscreen on a monitor">
410         Make the surface fullscreen.
411
412         You can specify an output that you would prefer to be fullscreen.
413         If this value is NULL, it's up to the compositor to choose which
414         display will be used to map this surface.
415
416         If the surface doesn't cover the whole output, the compositor will
417         position the surface in the center of the output and compensate with
418         black borders filling the rest of the output.
419       </description>
420       <arg name="output" type="object" interface="wl_output" allow-null="true"/>
421     </request>
422     <request name="unset_fullscreen" />
423
424     <request name="set_minimized">
425       <description summary="set the window as minimized">
426         Request that the compositor minimize your surface. There is no
427         way to know if the surface is currently minimized, nor is there
428         any way to unset minimization on this surface.
429
430         If you are looking to throttle redrawing when minimized, please
431         instead use the wl_surface.frame event for this, as this will
432         also work with live previews on windows in Alt-Tab, Expose or
433         similar compositor features.
434       </description>
435     </request>
436
437     <event name="close">
438       <description summary="surface wants to be closed">
439         The close event is sent by the compositor when the user
440         wants the surface to be closed. This should be equivalent to
441         the user clicking the close button in client-side decorations,
442         if your application has any...
443
444         This is only a request that the user intends to close your
445         window. The client may choose to ignore this request, or show
446         a dialog to ask the user to save their data...
447       </description>
448     </event>
449   </interface>
450
451   <interface name="xdg_popup" version="1">
452     <description summary="short-lived, popup surfaces for menus">
453       A popup surface is a short-lived, temporary surface that can be
454       used to implement menus. It takes an explicit grab on the surface
455       that will be dismissed when the user dismisses the popup. This can
456       be done by the user clicking outside the surface, using the keyboard,
457       or even locking the screen through closing the lid or a timeout.
458
459       When the popup is dismissed, a popup_done event will be sent out,
460       and at the same time the surface will be unmapped. The xdg_popup
461       object is now inert and cannot be reactivated, so clients should
462       destroy it. Explicitly destroying the xdg_popup object will also
463       dismiss the popup and unmap the surface.
464
465       Clients will receive events for all their surfaces during this
466       grab (which is an "owner-events" grab in X11 parlance). This is
467       done so that users can navigate through submenus and other
468       "nested" popup windows without having to dismiss the topmost
469       popup.
470
471       Clients that want to dismiss the popup when another surface of
472       their own is clicked should dismiss the popup using the destroy
473       request.
474
475       The parent surface must have either an xdg_surface or xdg_popup
476       role.
477
478       Specifying an xdg_popup for the parent means that the popups are
479       nested, with this popup now being the topmost popup. Nested
480       popups must be destroyed in the reverse order they were created
481       in, e.g. the only popup you are allowed to destroy at all times
482       is the topmost one.
483
484       If there is an existing popup when creating a new popup, the
485       parent must be the current topmost popup.
486
487       A parent surface must be mapped before the new popup is mapped.
488
489       When compositors choose to dismiss a popup, they will likely
490       dismiss every nested popup as well. When a compositor dismisses
491       popups, it will follow the same dismissing order as required
492       from the client.
493
494       The x and y arguments passed when creating the popup object specify
495       where the top left of the popup should be placed, relative to the
496       local surface coordinates of the parent surface. See
497       xdg_shell.get_xdg_popup.
498
499       The client must call wl_surface.commit on the corresponding wl_surface
500       for the xdg_popup state to take effect.
501
502       For a surface to be mapped by the compositor the client must have
503       committed both the xdg_popup state and a buffer.
504     </description>
505
506     <request name="destroy" type="destructor">
507       <description summary="remove xdg_popup interface">
508         This destroys the popup. Explicitly destroying the xdg_popup
509         object will also dismiss the popup, and unmap the surface.
510
511         If this xdg_popup is not the "topmost" popup, a protocol error
512         will be sent.
513       </description>
514     </request>
515
516     <event name="popup_done">
517       <description summary="popup interaction is done">
518         The popup_done event is sent out when a popup is dismissed by the
519         compositor. The client should destroy the xdg_popup object at this
520         point.
521       </description>
522     </event>
523
524   </interface>
525 </protocol>