A single `delegate_dispatch2!` replaces all other delegate macros.
When wayland-rs updates the definition of `Dispatch`, this macro will be
unnecessary, and `Dispatch` type bounds should become inferable by the
type system.
`Dispatch` is now implemented for the user-data type, so `smithay` is
able to provide blanket implementations as long as the user data is a
type owned by `smithay`. Therefore, `GlobalData` replaces `()` as a user
data (`smithay-client-toolkit` already did this), and udata that is
simply a type like `Weak<WlSurface>` is wrapped.
`smithay` already requires Rust 1.85.0, the version that introduces the
2024 edition. Updating to the new edition allows us to use if let
chains, etc.
To keep things simple here, this allows `unsafe_op_in_unsafe_fn` for
now, which is a warning by default in the 2024 edition.
Removing `ref` in various places is simple enough. The more complicated
issue here is "precise capture lists" using `use<..>`. This needs to be
manually added in various places for the API to still work as it does.
We also annoyingly need to turn some impl-trait arguments to explicitly
named type parameters:
https://doc.rust-lang.org/edition-guide/rust-2024/rpit-lifetime-capture.html#migrating-cases-involving-apit
With the fixes and adjustments that were missed during the review.
The new protocol errors were also relaxed to follow `wlroots` at this
time, since firefox does violate protocol a bit and thus crashing it
is not a great thing to do.
This reverts commit d34af7bfe0.
Smithay uses lazy notify when there's actual interaction, which is
unexpected and doesn't properly reflect the state of the clipboard to
clipboard managers. Instead immediately notify clients when the source
was destroyed by sending `null`.
Links: https://github.com/YaLTeR/niri/issues/1831
This new function is the same as `from_loc_and_size`, except it takes
concrete types as arguments instead of `impl Into`.
This matches `euclid::Rect`'s API, but it also seems a little better to
have strong typing without implicit conversion like this. In a few cases
it's not obvious that the argument is variable of tuple type, so there
is an implied assertion that the coordinate space is right.
The use of `#[deprecated]` makes this not entirely urgent for
compositors, but uses of this should be updated to `::new`, or other
functions like `from_size`.
A couple patterns are used for this already. This method makes it
consistent and a bit more concise.
This seems to cover a lot of the uses of `Rectangle::from_loc_and_size`.
It seems good to use a dedicated type for keycodes, particularly given
there's two conventions for keycodes, offset by 8. So there's ambiguity
about what the numberic value of the keycode actually represents.
We might prefer to use the Wayland value rather than the X11 version
like `xkeysym::KeyCode` uses. But it would complicate things to have two
different keycode types, and the code that calls `kbd.key` already is
converting from `Keycode`.
Make better winit integration by providing a calloop's WaylandSource
for it. The winit backend now doesn't use vsync and utilizes frame
callbacks, when the user cooperates and asks for `redraw_requested`.
Fixes#146.
wlr_data_control is a protocol used to implement clipboard managers or
access clipboard without creating a window. The implementation of it
ties to regular selections, thus the selection handling was unified
to reduce the maintainance burden.
The present selection modules, like `walyand/primary_selection` and
`wayland/data_device` moved into the new `wayland/selection` module.
Keeping their original implementation, where it was possible.
The new selection module uses the common structure of `seat_data`,
`device`, `source`, and `mod.rs` used in the said above modules, however
it uses the hand-rolled dynamic dispatch with the `selection_dispatch!`
macro. The offers and selection replies are all handled together,
so the code is unique in the most cases.
As a side effect of the selection update and merging the handling of
the primary and clipboard selection into the single `SelectionHandler`
trait (users could still just use one of them, it's not a must to have
both), the xwayland was changed to use some types from the
`wayland/selection` module.
this can give the backend a hint about how to handle
the element.
for now the only supported use-case is to not accidentally
assign non cursor content to the cursor plane
