If the surface under the pointer has changed, we should send an `enter`
event immediately, instead of waiting for the next motion event. This
seems to fix that, without producing unnecessary events.
Instead of `time: 0`, this and other synthesized events should probably
use `CLOCK_MONOTONIC`. It seems libinput does document that it uses
that.
It would make sense to have a bound like
`for<'frame> R::Frame<'frame>: AsGlowFrame<'frame>`. But that appears to
not behave properly due to current limitations of the borrow checker:
https://blog.rust-lang.org/2022/10/28/gats-stabilization.html#implied-static-requirement-from-higher-ranked-trait-bounds
Instead, this makes `glow_frame` and `glow_frame_mut` associated
functions of the `AsGlowRenderer` trait. Then it is pretty
straightforward to make the `RenderElement` implementations generic
using that and `FromGlesError`.
It would make sense to make `Self::Error: FromGlessError` a requirement
of the `AsGlowRenderer` trait, but due to the lack of implied bounds
support, that produces a bunch of errors about missing bounds. If Rustc
improves that eventually, some bounds could be cleaned up a bit:
https://github.com/rust-lang/rust/issues/44491
This is increasingly not just related to screencopy, so it's weird to
add there. I don't see any other module that fits, so add one called
"quirks" (like the Linux kernel uses for device-specific handling in
generic drives).
Fixes https://github.com/pop-os/cosmic-workspaces-epoch/issues/27.
We want this to apply to changes to workspace either through keybindings
or the cosmic-workspaces UI, so it adding a check here seems reasonable.
In principle it could be good to have some kind of privileged protocol
for setting things like this.
We may also want a configuration option to disable animations at some
point.
`(w_elements, p_elements)` tuples are used in a bunch of places. A
struct with named fields is generally an improvement just due to the
fact the order is non-obvious.
But we can also add methods. In particular,
`extend_from_workspace_elements` abstracts out some of the more
redundant code in `workspace_elements`.
It would be nice to avoid allocation everywhere, but iterators would
complicate lifetimes, run into issues with needing multiple mutable
borrows to things like the `Renderer`, and be awkward in certain
functions without generator syntax. In any case, cosmic-comp already
relies on allocating vectors here.
If this abstraction is commonly useful in compositors, perhaps it could
be moved to Smithay.
