Since the range end was always encoded in the data length, calculating
the end of the selection is a bit cleaner and removes a potentially
confusing slice operation on a slice.
Resolve Clippy's `too_many_arguments` lint on
`handle_selection_request` by removing the `success` and `refuse`
parameters and returning a bool indicating which needs to be run.
Use the helper functions defined last commit to simplify
`incr_copy_from_x11`
Reduce the `match` statement checking if the target is the TARGET
atom to an if statement. Although using `match` statements as
`if`/`else if`/`else` chains occur elsewhere, this one is both only 2
cases, and already of particular relevance to the current work.
Refactor `paste_impl` to be much easier to read. I did this code algebra
way back while investigating #142, but since I never figured that out,
the change has just been sitting in my stash.
refactor: simplify paste_data logic, some unnests
Since the connection handshake establishes the most data a request can
send, if the data length exceeds that limit, we can follow ICCCM 2.7.2
sending the INCR property and continuing to send data via PropertyNotify
events.
To test the changes, we create `XState::set_max_req_bytes` to forcefully
trigger the INCR mechanism in integration test runs with a constant,
substantially less amount of data.
I found an oversight where trying to transfer too much data (16 MiB
in my case) from a Wayland selection to an X window causes the X
connection to be unable to poll the event with a `ClosedReqLenExceed`
error.
To replicate, start `xwls`, use `wl-copy` to copy more data than the
`maximum-request-size` to the Wayland selection, then attempt to
transfer that selection to an X program. I found this easy to do
transferring a large, random `.bmp` file to Krita by creating its new
image from clipboard functionality.
This test replicates the observed behavior and obtains the same
panic, to be used as a starting point for implementing incremental
selections from Wayland to X.
xcb-util-cursor made another patch release to revert back to Rust 2021
edition, so we bump to that.
Also create a function, `timespec_from_millis` to make creating
`Timespec` for using in `poll` calls a lot more ergonomic.
By using conditional compilation, we now support running the test suite
with Rust versions 1.83 to 1.86 again. This allows us to lower the
`rust-version` specified in the root Cargo.toml (because it was
controlling the toolchain used in CI) to 1.83, resolving #230.
This solution keeps tests operational on our MSRV while also lowering
it. It would have been unsatisfying to have an MSRV which could not
compile the tests.
`rustversion` was selected as the dependency to control the conditional
compilation since it was already a build dependency needed by
`vergen-gitcl`, so no new dependencies were added.
The wl_keyboard Enter event, wl_keyboard Leave event, the wl_touch
Self::Down event and the ServerState::reconfigure_window function had
similar uses of `unwrap` which appear to not consider the distinct
query preparation and query execution stages.
Regression from 799027d1. Unwraps on a None value when doing the stale surface generation technique in Chatterino7 as described in #74, very consistent
This should simplify how some of the code reads, as well as allowing for future
feature additions to be accomplished in a less restrictive manner. The slotmap +
Object enum pattern was kind of like a really bad ecs in a way anyway. Also I
was looking for an excuse to use an ecs.
Just exits with 0. Useful to test whether xwayland-satellite supports -listenfd
before setting up the X11 sockets and stuff on the compositor side. Versions
before this commit panic and exit with nonzero code.
