mirror of
https://gitlab.freedesktop.org/wayland/wayland.git
synced 2025-10-29 05:40:16 -04:00
Core Wayland window system code and protocol
da7b248904
These 2 requests have been added: - wl_data_source.set_actions: Notifies the compositor of the available actions on the data source. - wl_data_offer.set_actions: Notifies the compositor of the available actions on the destination side, plus the preferred action. Out of the data from these requests, the compositor can determine the action both parts agree on (and let the user play a role through eg. keyboard modifiers). The chosen option will be notified to both parties through the following two requests: - wl_data_source.action - wl_data_offer.action In addition, the destination side can peek the source side actions through wl_data_offer.source_actions. Compared to the XDND protocol, there's two notable changes: - XDND lets the source suggest an action, whereas wl_data_device lets the destination prefer a given action. The difference is subtle here, it comes off as convenience because it is the drag destination which receives the motion events (unlike in X) and can perform action updates. The drag destination seems also in a better position to update the preferred action based on things like the data being transferred, the place being dropped, and whether the drag is client-local. - That same source-side preferred action is used in XDND to convey the modifier-induced action to the drag destination, which would then ack it, or reply with another action that's accepted (or none), this makes the XdndPosition/XdndStatus messaging very verbose, and synchronous because the drag source always needs to know the latest status/action for every position+action sent. Here it's the compositor which takes care of modifiers and matching available/accepted actions, this allows for the signaling to happen only whenever the actions/modifiers change for real. Roughly based on previous work by Giulio Camuffo <giuliocamuffo@gmail.com> Changes since v10: - Narrow down the situations where wl_data_source/offer.accept requests are supposed to happen. Changes since v9: - Deferred the protocol errors to .finish after some IRC chat with Jonas, added further errors if actions API is used on selection sources/offers. Changes since v8: - Defined further the expected behavior on "ask", described the protocol errors that may happen. Fix more spaces vs tabs issues. Changes since v7: - Misc changes after updating the progress notification patch. Changes since v6: - Further explanations on wl_data_source/offer.set_actions, including a description of "ask" actions. Added protocol errors for unknown action values. Changes since v5: - Applied rewording suggestions from Jonas Ådahl. Dropped slot reservation scheme for actions. Fixed indentation and other minor formatting issues. Changes since v4: - Minor rewording. Changes since v3: - Splitted from DnD progress notification changes. - Further rationales in commit log. Changes since v2: - Renamed notify_actions to set_actions on both sides, seems more consistent with the rest of the protocol. - Spelled out better which events may be triggered on the compositor side by the requests, the circumstances in which events are emitted, and what are events useful for in clients. - Defined a minimal common ground wrt compositor-side action picking and keybindings. - Acknowledge the possibility of compositor/toolkit defined actions, even though none are used at the moment. Changes since v1: - Added wl_data_offer.source_actions to let know of the actions offered by a data source. - Renamed wl_data_source.finished to "drag_finished" for clarity - Improved wording as suggested by Bryce Signed-off-by: Carlos Garnacho <carlosg@gnome.org> Reviewed-by: Michael Catanzaro <mcatanzaro@igalia.com> Reviewed-by: Mike Blumenkrantz <zmike@samsung.com> Reviewed-by: Jonas Ådahl <jadahl@gmail.com> Reviewed-by: Bryce Harrington <bryce@osg.samsung.com> |
||
|---|---|---|
| cursor | ||
| doc | ||
| m4 | ||
| protocol | ||
| spec | ||
| src | ||
| tests | ||
| .gitignore | ||
| autogen.sh | ||
| configure.ac | ||
| COPYING | ||
| Makefile.am | ||
| publish-doc | ||
| README | ||
| TODO | ||
| wayland-scanner.m4 | ||
| wayland-scanner.mk | ||
What is Wayland?
Wayland is a project to define a protocol for a compositor to talk to
its clients as well as a library implementation of the protocol. The
compositor can be a standalone display server running on Linux kernel
modesetting and evdev input devices, an X application, or a wayland
client itself. The clients can be traditional applications, X servers
(rootless or fullscreen) or other display servers.
The wayland protocol is essentially only about input handling and
buffer management. The compositor receives input events and forwards
them to the relevant client. The clients creates buffers and renders
into them and notifies the compositor when it needs to redraw. The
protocol also handles drag and drop, selections, window management and
other interactions that must go through the compositor. However, the
protocol does not handle rendering, which is one of the features that
makes wayland so simple. All clients are expected to handle rendering
themselves, typically through cairo or OpenGL.
The weston compositor is a reference implementation of a wayland
compositor and the weston repository also includes a few example
clients.
Building the wayland libraries is fairly simple, aside from libffi,
they don't have many dependencies:
$ git clone git://anongit.freedesktop.org/wayland/wayland
$ cd wayland
$ ./autogen.sh --prefix=PREFIX
$ make
$ make install
where PREFIX is where you want to install the libraries. See
http://wayland.freedesktop.org for more complete build instructions
for wayland, weston, xwayland and various toolkits.