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