Be notified of new releases
Create your free GitHub account today to subscribe to this repository for new releases and build software alongside 31 million developers.Sign up
This version brings one single major change in the way the cargo feature
native_lib is organized.
This feature now no longer affects the contents of the code generated by
wayland-scanner, which is thus now always compatible with both the C lib implementation and the rust one. As a consequence, the
native_lib cargo feature is now only present on
wayland-server, and no longer on
wayland-protocols. Meaning that there is not going to be any more issues with synchronizing these features correctly between the crates (not doing so could lead to hard-to-understand build errors).
So now, if your project requires
native_lib, put it on
wayland-server as required, and interaction with other projects in your dependency tree (for example if using SCTK) will just work, no question asked.
An other consequence of this refactor is that now the implementations of the protocols can be cross-tested against each other. Meaning that the project's CI now runs rust-based
wayland-client and C-based
wayland-client against both rust-based and C-based
This release brings yet another large redesign of the wayland-rs, many thanks to @YaLTeR for their help redesigning the API.
The most notable changes are as follow.
Objects have been transformed
The main objects that are manipulated are no longer
WlFoo objects directly (with access to the underlying
Proxy via the
AsRef trait and
Into conversions (and similarly server-side with the
Associated with this
RequestTraits are no longer, being replaced by inherent method on the
WlFoo objects directly, for improved ergonomy, as you don't need to import all those traits any longer. Server-side objects now also have these methods.
Diversification of implementations
It is now possible to implement an object using a closure (as previously) or a struct implementing the associated
EventHandler trait, depending on which is more practical for you.
It is also no longer unsafe to use a non-threadsafe implementation for objects, and it is now the default, as most use-case don't need the thread-safety anyway. It is still possible to opt-in into the safety though, if you need it.
If your workflow is more geared towards processing events in an iterator-like fashion rather than via callbacks, you can now use sinks. These are mpsc queues that can be used to implement any object. All objects implemented with a given sink will feed their event in a
MsgIterator, that implements the
Iterator trait. The
BlockingMsgIter variant will additionally block on the wayland socket waiting for other events to arrive, allowing you to reduce your main event loop to a simple
for loop, if you don't need to handle other sources of events.
Future-proofing the protocols
The enums generated from the protocol definitions are now explicitly nonexhaustive, as adding variants to them (enums, events and requests) is considered semver-compatible in Wayland land. This means that updating the protocol files is no longer a potential breaking change as it used to be.
The pure rust implementation of the protocol is now much more strict about its state-keeping. Several issues about race conditions at the protocol level have been identified, fixed, and are now tested against. This process even managed to find a bug in the reference implementation (although a bug that is quite unlikely to trigger in practice).
For more details, you can check the full changelog.