Skip to content
Mar 24, 2019
0.23.1 -- 2019-03-24
Dependencies updates

- `nix` to 0.13

@vberger vberger released this Feb 17, 2019 · 3 commits to master since this release

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-client and 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-client / 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 wayland-server.

Assets 2
Feb 16, 2019
0.22.2 -- 2019-02-16
- [protocols] Update `wlr-protocols` (`data-control` version 2).
Feb 13, 2019
0.22.1 -- 2019-02-13
- [client] Fix a potential race when the client destroys an object after pending events
  for it have already been queued in the event queue
- [client] Expose `Display::protocol_error()` to get the details of a protocol error
  that occured.
- [client] Don't try to connect to `wayland-0` if `WAYLAND_DISPLAY` is not set, this is a
  bad legacy practice which can cause clients to spawn in the wrong environment.
- [client] `Display` can now be cloned and sent accross threads as nothing prevents it

@vberger vberger released this Jan 31, 2019 · 19 commits to master since this release

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 Proxy<WlFoo>, but WlFoo objects directly (with access to the underlying Proxy via the AsRef trait and From/Into conversions (and similarly server-side with the Resources).

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.

General robustification

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.

Assets 2
You can’t perform that action at this time.