v0.3.0 7942c6b

ext-foreign-toplevel-list-v1.xml RawHistoryFolder

1<?xml version="1.0" encoding="UTF-8"?>
2<protocol name="ext_foreign_toplevel_list_v1">
3  <copyright>
4    Copyright © 2018 Ilia Bozhinov
5    Copyright © 2020 Isaac Freund
6    Copyright © 2022 wb9688
7    Copyright © 2023 i509VCB
8
9    Permission to use, copy, modify, distribute, and sell this
10    software and its documentation for any purpose is hereby granted
11    without fee, provided that the above copyright notice appear in
12    all copies and that both that copyright notice and this permission
13    notice appear in supporting documentation, and that the name of
14    the copyright holders not be used in advertising or publicity
15    pertaining to distribution of the software without specific,
16    written prior permission.  The copyright holders make no
17    representations about the suitability of this software for any
18    purpose.  It is provided "as is" without express or implied
19    warranty.
20
21    THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
22    SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
23    FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
24    SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
25    WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
26    AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
27    ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
28    THIS SOFTWARE.
29  </copyright>
30
31  <description summary="list toplevels">
32    The purpose of this protocol is to provide protocol object handles for
33    toplevels, possibly originating from another client.
34
35    This protocol is intentionally minimalistic and expects additional
36    functionality (e.g. creating a screencopy source from a toplevel handle,
37    getting information about the state of the toplevel) to be implemented
38    in extension protocols.
39
40    The compositor may choose to restrict this protocol to a special client
41    launched by the compositor itself or expose it to all clients,
42    this is compositor policy.
43
44    The key words "must", "must not", "required", "shall", "shall not",
45    "should", "should not", "recommended",  "may", and "optional" in this
46    document are to be interpreted as described in IETF RFC 2119.
47
48    Warning! The protocol described in this file is currently in the testing
49    phase. Backward compatible changes may be added together with the
50    corresponding interface version bump. Backward incompatible changes can
51    only be done by creating a new major version of the extension.
52  </description>
53
54  <interface name="ext_foreign_toplevel_list_v1" version="1">
55    <description summary="list toplevels">
56      A toplevel is defined as a surface with a role similar to xdg_toplevel.
57      XWayland surfaces may be treated like toplevels in this protocol.
58
59      After a client binds the ext_foreign_toplevel_list_v1, each mapped
60      toplevel window will be sent using the ext_foreign_toplevel_list_v1.toplevel
61      event.
62
63      Clients which only care about the current state can perform a roundtrip after
64      binding this global.
65
66      For each instance of ext_foreign_toplevel_list_v1, the compositor must
67      create a new ext_foreign_toplevel_handle_v1 object for each mapped toplevel.
68
69      If a compositor implementation sends the ext_foreign_toplevel_list_v1.finished
70      event after the global is bound, the compositor must not send any
71      ext_foreign_toplevel_list_v1.toplevel events.
72    </description>
73
74    <event name="toplevel">
75      <description summary="a toplevel has been created">
76        This event is emitted whenever a new toplevel window is created. It is
77        emitted for all toplevels, regardless of the app that has created them.
78
79        All initial properties of the toplevel (identifier, title, app_id) will be sent
80        immediately after this event using the corresponding events for
81        ext_foreign_toplevel_handle_v1. The compositor will use the
82        ext_foreign_toplevel_handle_v1.done event to indicate when all data has
83        been sent.
84      </description>
85      <arg name="toplevel" type="new_id" interface="ext_foreign_toplevel_handle_v1"/>
86    </event>
87
88    <event name="finished">
89      <description summary="the compositor has finished with the toplevel manager">
90        This event indicates that the compositor is done sending events
91        to this object. The client should destroy the object.
92        See ext_foreign_toplevel_list_v1.destroy for more information.
93
94        The compositor must not send any more toplevel events after this event.
95      </description>
96    </event>
97
98    <request name="stop">
99      <description summary="stop sending events">
100        This request indicates that the client no longer wishes to receive
101        events for new toplevels.
102
103        The Wayland protocol is asynchronous, meaning the compositor may send
104        further toplevel events until the stop request is processed.
105        The client should wait for a ext_foreign_toplevel_list_v1.finished
106        event before destroying this object.
107      </description>
108    </request>
109
110    <request name="destroy" type="destructor">
111      <description summary="destroy the ext_foreign_toplevel_list_v1 object">
112        This request should be called either when the client will no longer
113        use the ext_foreign_toplevel_list_v1 or after the finished event
114        has been received to allow destruction of the object.
115
116        If a client wishes to destroy this object it should send a
117        ext_foreign_toplevel_list_v1.stop request and wait for a ext_foreign_toplevel_list_v1.finished
118        event, then destroy the handles and then this object.
119      </description>
120    </request>
121  </interface>
122
123  <interface name="ext_foreign_toplevel_handle_v1" version="1">
124    <description summary="a mapped toplevel">
125      A ext_foreign_toplevel_handle_v1 object represents a mapped toplevel
126      window. A single app may have multiple mapped toplevels.
127    </description>
128
129    <request name="destroy" type="destructor">
130      <description summary="destroy the ext_foreign_toplevel_handle_v1 object">
131        This request should be used when the client will no longer use the handle
132        or after the closed event has been received to allow destruction of the
133        object.
134
135        When a handle is destroyed, a new handle may not be created by the server
136        until the toplevel is unmapped and then remapped. Destroying a toplevel handle
137        is not recommended unless the client is cleaning up child objects
138        before destroying the ext_foreign_toplevel_list_v1 object, the toplevel
139        was closed or the toplevel handle will not be used in the future.
140
141        Other protocols which extend the ext_foreign_toplevel_handle_v1
142        interface should require destructors for extension interfaces be
143        called before allowing the toplevel handle to be destroyed.
144      </description>
145    </request>
146
147    <event name="closed">
148      <description summary="the toplevel has been closed">
149        The server will emit no further events on the ext_foreign_toplevel_handle_v1
150        after this event. Any requests received aside from the destroy request must
151        be ignored. Upon receiving this event, the client should destroy the handle.
152
153        Other protocols which extend the ext_foreign_toplevel_handle_v1
154        interface must also ignore requests other than destructors.
155      </description>
156    </event>
157
158    <event name="done">
159      <description summary="all information about the toplevel has been sent">
160        This event is sent after all changes in the toplevel state have
161        been sent.
162
163        This allows changes to the ext_foreign_toplevel_handle_v1 properties
164        to be atomically applied. Other protocols which extend the
165        ext_foreign_toplevel_handle_v1 interface may use this event to also
166        atomically apply any pending state.
167
168        This event must not be sent after the ext_foreign_toplevel_handle_v1.closed
169        event.
170      </description>
171    </event>
172
173    <event name="title">
174      <description summary="title change">
175        The title of the toplevel has changed.
176
177        The configured state must not be applied immediately. See
178        ext_foreign_toplevel_handle_v1.done for details.
179      </description>
180      <arg name="title" type="string"/>
181    </event>
182
183    <event name="app_id">
184      <description summary="app_id change">
185        The app id of the toplevel has changed.
186
187        The configured state must not be applied immediately. See
188        ext_foreign_toplevel_handle_v1.done for details.
189      </description>
190      <arg name="app_id" type="string"/>
191    </event>
192
193    <event name="identifier">
194      <description summary="a stable identifier for a toplevel">
195        This identifier is used to check if two or more toplevel handles belong
196        to the same toplevel.
197
198        The identifier is useful for command line tools or privileged clients
199        which may need to reference an exact toplevel across processes or
200        instances of the ext_foreign_toplevel_list_v1 global.
201
202        The compositor must only send this event when the handle is created.
203
204        The identifier must be unique per toplevel and its handles. Two different
205        toplevels must not have the same identifier. The identifier is only valid
206        as long as the toplevel is mapped. If the toplevel is unmapped the identifier
207        must not be reused. An identifier must not be reused by the compositor to
208        ensure there are no races when sharing identifiers between processes.
209
210        An identifier is a string that contains up to 32 printable ASCII bytes.
211        An identifier must not be an empty string. It is recommended that a
212        compositor includes an opaque generation value in identifiers. How the
213        generation value is used when generating the identifier is implementation
214        dependent.
215      </description>
216      <arg name="identifier" type="string"/>
217    </event>
218  </interface>
219</protocol>

Keyboard shortcuts

Single-key shortcuts are on. ctrl k and esc work whatever this says.

ctrl k :
go to a section, branch, tag, file or repository
?
this list
j k
move the row cursor down / up
enter
open the row under the cursor; on Files, a directory opens or closes in place
↑ ↓ ← → home end
in the file tree (focus on a row): previous / next row, close / open a directory or go to its parent / first entry, first / last row. They never open a file
l h
on Files: open a directory or a file / close a directory or go up to its parent, then to the parent page. Elsewhere: into the side panel (on a merge request, its files) / back to the content; there j k move between its controls
g g G
first / last row
/
filter the list; on Files, find a file anywhere in the repository (esc clears, enter opens the best match)
b
switch branch or tag
g s g f g c g b g m g i g r g a
tabs: summary, files, commits, branches & tags, merge requests, issues, releases, actions (when available)
g h
home
w
wide mode: use the whole width of the screen, or not (remembered)
y
copy a permalink pinned to the commit
d u x
diff: split / unified / collapse or expand all
e E
diff: the whole file in view / every file, with the lines the hunks hide
n
merge request: next note in the diff
esc
close a dialog, leave a field

Branches 1

Tags 14

↑↓ moveenter openesc close