Do not follow this link

~nickbp/nikau

Try to recreate XContext when getting errors reading clipboard (like 'The write buffer was corrupted' after KDE crash)
Cut 0.3.2: fix new keypairs
Fix initial keypair output: wasn't writing the cert
Fix script warning on dash systems
Bump to 0.3.1, mainly due to bug fix
Fix cert confirmation blocking server input: Run input and connections on separate loops
Bump quinn 0.10->0.11 and rustls 0.21->0.23: was blocked on quinn upgrade (PR #1715)
Bump some deps: avoid clap 4.5 which breaks everything, and waiting on quinn 0.11 to upgrade rustls and rcgen
Cut 0.3.0, bump deps, cargo fmt
Drop the last button press from a combo at the server too: Always grab keyboards at the server, while mice/touchpads continue to pass through
Update event->device routing to avoid reordering events across types
cargo fmt: examples
Fix examples build
Detect when a given input device has keys relevant to one or more configured key shortcuts - just logging a debug message for now
Break out shortcut handling into separate module, parse shortcut config strings up front
When the user completes a combo, consume the last keypress/release of the combo.

For example if the combo is ALT,N (in that order) then we consume the N keypress/release. If the user instead presses N,ALT then we consume the ALT keypress/release.

We only do this for the LAST key because it'll look like keys are broken if we speculatively consume all keys in the combo. In the ALT+N case, consuming all keys would make it look like the N key doesn't work or is delayed, since we'd keep grabbing it until it's apparent that a combo isn't being performed, like when a different key outside the combo is pressed. On top of that, there'd also be correctly handling the case when N is being held down. And then finally, there's the fact that multiple combos could be activated by the same key, like the ALT+P/ALT+N defaults.

For now this consume only applies when sending input to remote clients, since we don't grab server-local input (yet), so server->client switches will still see the last key emitted at the server.
Prepare for 0.3.0 (protocol version change), not published yet
Next
Do not follow this link