An unwrap was hit when a pointer event with no CurrentSurface was
processed. To resolve this, the same logic from the Event::Motion case
has been abstracted to a `handle_pending enter` lambda to provide a
valid CurrentSurface or return early if none could be entered.
Though the effect of `handle_pending_enter` remains, its flow has been
refactored, both to move the `None` case code outside the lambda and
to remove the unnecessary recursion. I would have used a `while let`
loop instead of the `loop let else` construct, but the borrow checker
did some mental gymnastics and rejected it.
The catch-all case of `handle_client_message` now logs the atom's name
instead of its opaque atom id.
`get_atom_name` now warns there was an error and returns a filler name.
Since most the use of `get_atom_name` is in logging, this makes those
logs easier to read.
The integration tests now use `formatted_timed_builder` logger
constructor, which should unify the look of logs between the integration
tests and the main binary.
LuckShiba's commit was not formatted with `rustfmt`, so I took the
opportunity to do some additional refactors.
Some bulky match constructions in xstate/selection were made more
compact as well.
Allows popups that would normally go offscreen to stay visible. X11 doesn't seem
to like windows whose bounds go less than 0x0, so we adjust the position
reported to X11 to make it happy.
I am worried this will have some other implications with popups, but we'll see
what happens.
This behavior was removed a while back, because we were also trying to activate
popups and this was causing issues on some compositors. However, I think
activating toplevels after they're mapped is the behavior that X11 apps tend to
expect - in Steam Big Picture for example, when launching a game in Niri while
fullscreened, the focus doesn't automatically switch to the game. This may need
to be reevaluated and refined in the future though.
Brought to my attention by #252, several `unwrap`s exist on code whose
failure does not justify the termination of the program, so I took some
time to replace them with proper error handling.
The request for TARGETS in `handle_selection_request` used `unwrap`.
Since the code for a failure of responsing to `SelectionRequest` exists,
it simply uses that.
`handle_target_list` now early returns if receiving the
`GetProperty` request fails.
`handle_new_owner` does not update the timestamp for the last selection
on failure.
`set_owner` now returns a `bool` to indicate whether the
`SetSelectionOwner` and `GetSelectionOwner` requests succeeded and
whether they transferred ownership successfully or not. The call spots
have also been modified to not change the `selection_state` if this call
fails.
Due to an oversight, if `XState` had both a valid primary selection
and a valid clipboard selection, `handle_selection_property_change`
would early return after `check_for_incr` determines the primary selection
existed but was not the recipient of the `PropertyNotifyEvent`, preventing
INCR events from ever reaching the clipboard. An addtion to the
`incr_copy_from_x11` integration test validates this fix.
Also fixed was a missing check in `WaylandSelection`'s `check_for_incr`
to confirm the property requesting more data is indeed the property the
selection is responsible for. I could not figure out how to write an
integration for this mistake, but it is obvious enough in hindsight.
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.
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.
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.
