1//! Protocols related to window management
2
3#![cfg_attr(rustfmt, rustfmt_skip)]
4
5#[cfg(feature = "staging")]
6pub mod activation {
7 //! The way for a client to pass focus to another toplevel is as follows.
8 //!
9 //! The client that intends to activate another toplevel uses the
10 //! xdg_activation_v1.get_activation_token request to get an activation token.
11 //! This token is then passed to the client to be activated through a separate
12 //! band of communication. The client to be activated will then pass the token
13 //! it received to the xdg_activation_v1.activate request. The compositor can
14 //! then use this token to decide how to react to the activation request.
15 //!
16 //! The token the activating client gets may be ineffective either already at
17 //! the time it receives it, for example if it was not focused, for focus
18 //! stealing prevention. The activating client will have no way to discover
19 //! the validity of the token, and may still forward it to the to be activated
20 //! client.
21 //!
22 //! The created activation token may optionally get information attached to it
23 //! that can be used by the compositor to identify the application that we
24 //! intend to activate. This can for example be used to display a visual hint
25 //! about what application is being started.
26
27 #[allow(missing_docs)]
28 pub mod v1 {
29 wayland_protocol!(
30 "./protocols/staging/xdg-activation/xdg-activation-v1.xml",
31 []
32 );
33 }
34}
35
36#[cfg(feature = "unstable")]
37pub mod decoration {
38 //! This interface allows a compositor to announce support for server-side
39 //! decorations.
40
41 //! A window decoration is a set of window controls as deemed appropriate by
42 //! the party managing them, such as user interface components used to move,
43 //! resize and change a window's state.
44
45 //! A client can use this protocol to request being decorated by a supporting
46 //! compositor.
47
48 //! If compositor and client do not negotiate the use of a server-side
49 //! decoration using this protocol, clients continue to self-decorate as they
50 //! see fit.
51
52 /// Unstable version 1
53 pub mod zv1 {
54 wayland_protocol!(
55 "./protocols/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml",
56 [crate::xdg::shell]
57 );
58 }
59}
60
61#[cfg(feature = "unstable")]
62pub mod foreign {
63 //! Protocol for exporting xdg surface handles
64 //!
65 //! This protocol specifies a way for making it possible to reference a surface
66 //! of a different client. With such a reference, a client can, by using the
67 //! interfaces provided by this protocol, manipulate the relationship between
68 //! its own surfaces and the surface of some other client. For example, stack
69 //! some of its own surface above the other clients surface.
70 //!
71 //! In order for a client A to get a reference of a surface of client B, client
72 //! B must first export its surface using xdg_exporter.export. Upon doing this,
73 //! client B will receive a handle (a unique string) that it may share with
74 //! client A in some way (for example D-Bus). After client A has received the
75 //! handle from client B, it may use xdg_importer.import to create a reference
76 //! to the surface client B just exported. See the corresponding requests for
77 //! details.
78 //!
79 //! A possible use case for this is out-of-process dialogs. For example when a
80 //! sandboxed client without file system access needs the user to select a file
81 //! on the file system, given sandbox environment support, it can export its
82 //! surface, passing the exported surface handle to an unsandboxed process that
83 //! can show a file browser dialog and stack it above the sandboxed client's
84 //! surface.
85
86 /// Unstable version 1
87 pub mod zv1 {
88 wayland_protocol!(
89 "./protocols/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml",
90 []
91 );
92 }
93
94 /// Unstable version 2
95 pub mod zv2 {
96 wayland_protocol!(
97 "./protocols/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml",
98 []
99 );
100 }
101}
102
103#[cfg(feature = "unstable")]
104pub mod xdg_output {
105 //! Protocol to describe output regions
106 //!
107 //! This protocol aims at describing outputs in a way which is more in line
108 //! with the concept of an output on desktop oriented systems.
109 //!
110 //! Some information are more specific to the concept of an output for
111 //! a desktop oriented system and may not make sense in other applications,
112 //! such as IVI systems for example.
113 //!
114 //! Typically, the global compositor space on a desktop system is made of
115 //! a contiguous or overlapping set of rectangular regions.
116 //!
117 //! Some of the information provided in this protocol might be identical
118 //! to their counterparts already available from wl_output, in which case
119 //! the information provided by this protocol should be preferred to their
120 //! equivalent in wl_output. The goal is to move the desktop specific
121 //! concepts (such as output location within the global compositor space,
122 //! the connector name and types, etc.) out of the core wl_output protocol.
123
124 /// Unstable version 1
125 pub mod zv1 {
126 wayland_protocol!(
127 "./protocols/unstable/xdg-output/xdg-output-unstable-v1.xml",
128 []
129 );
130 }
131}
132
133pub mod shell {
134 //! XDG Shell protocol
135 //!
136 //! Exposes the `xdg_wm_base` global, which deprecates and replaces `wl_shell`.
137
138 wayland_protocol!(
139 "./protocols/stable/xdg-shell/xdg-shell.xml",
140 []
141 );
142}
143
144#[cfg(feature = "staging")]
145pub mod toplevel_drag {
146 //! This protocol enhances normal drag and drop with the ability to move a
147 //! window at the same time. This allows having detachable parts of a window
148 //! that when dragged out of it become a new window and can be dragged over
149 //! an existing window to be reattached.
150 //!
151 //! A typical workflow would be when the user starts dragging on top of a
152 //! detachable part of a window, the client would create a `wl_data_source` and
153 //! a `xdg_toplevel_drag_v1` object and start the drag as normal via
154 //! `wl_data_device.start_drag`. Once the client determines that the detachable
155 //! window contents should be detached from the originating window, it creates
156 //! a new `xdg_toplevel` with these contents and issues a
157 //! `xdg_toplevel_drag_v1.attach` request before mapping it. From now on the new
158 //! window is moved by the compositor during the drag as if the client called
159 //! `xdg_toplevel.move`.
160 //!
161 //! Dragging an existing window is similar. The client creates a
162 //! `xdg_toplevel_drag_v1` object and attaches the existing toplevel before
163 //! starting the drag.
164 //!
165 //! Clients use the existing drag and drop mechanism to detect when a window
166 //! can be docked or undocked. If the client wants to snap a window into a
167 //! parent window it should delete or unmap the dragged top-level. If the
168 //! contents should be detached again it attaches a new toplevel as described
169 //! above. If a drag operation is cancelled without being dropped, clients
170 //! should revert to the previous state, deleting any newly created windows
171 //! as appropriate. When a drag operation ends as indicated by
172 //! `wl_data_source.dnd_drop_performed` the dragged toplevel window's final
173 //! position is determined as if a `xdg_toplevel_move` operation ended.
174
175 /// Version 1
176 pub mod v1 {
177 wayland_protocol!(
178 "./protocols/staging/xdg-toplevel-drag/xdg-toplevel-drag-v1.xml",
179 [crate::xdg::shell]
180 );
181 }
182}
183
184#[cfg(feature = "staging")]
185pub mod dialog {
186 //! The `xdg_wm_dialog_v1` interface is exposed as a global object allowing
187 //! to register surfaces with a xdg_toplevel role as "dialogs" relative to
188 //! another toplevel.
189 //!
190 //! The compositor may let this relation influence how the surface is
191 //! placed, displayed or interacted with.
192
193 /// Version 1
194 pub mod v1 {
195 wayland_protocol!(
196 "./protocols/staging/xdg-dialog/xdg-dialog-v1.xml",
197 [crate::xdg::shell]
198 );
199 }
200}
201
202#[cfg(feature = "staging")]
203pub mod toplevel_icon {
204 //! This protocol allows clients to set icons for their toplevel surfaces
205 //! either via the XDG icon stock (using an icon name), or from pixel data.
206 //!
207 //! A toplevel icon represents the individual toplevel (unlike the application
208 //! or launcher icon, which represents the application as a whole), and may be
209 //! shown in window switchers, window overviews and taskbars that list
210 //! individual windows.
211
212 /// Version 1
213 pub mod v1 {
214 wayland_protocol!(
215 "./protocols/staging/xdg-toplevel-icon/xdg-toplevel-icon-v1.xml",
216 [crate::xdg::shell]
217 );
218 }
219}
220
221#[cfg(feature = "staging")]
222pub mod system_bell {
223 //! This global interface enables clients to ring the system bell.
224
225 /// Version 1
226 pub mod v1 {
227 wayland_protocol!(
228 "./protocols/staging/xdg-system-bell/xdg-system-bell-v1.xml",
229 []
230 );
231 }
232}
233