-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement one-shot functionality #93
Conversation
This is for #62 |
I found an issue where double-pressing the one-shot key causes the key to remain released even while still held. I will push a fix shortly. |
Issue is fixed and a test added. |
Maybe the release of the one shot should be at the first not one shot release, allowing to:
Or maybe not? (it might cause one shot shift + rowling not doing the intented behavior). |
I think it's better to allow the chaining of multiple one shot keys rather than end-on-release. Ending the one-shot on first not-one-shot-release rather than the first not-one-shot-press seems like it could be surprising behaviour. What do you think of adding this to the PR:
|
What's the behavior in QMK and ZMK? If that's it for the 2, I'm OK with it. |
From reading the documentation:
|
What about: OneShot(&'static OneShot), // for the small action object, see previous PR
// ...
#[derive(Debug, Clone, Copy, Eq, PartialEq)]
pub struct OneShot<T> {
/// Action to activate until timeout expires or exactly one keypress is activated.
action: Action<T>,
/// Timeout after which one-shot will expire.
timeout: u16,
/// configuration of the one shot behavior
config: OneShotConfig
}
#[non_exhaustive]
#[derive(Debug, Clone, Copy, Eq, PartialEq)]
pub enum OneShotConfig {
OnFirstPress,
OnFirstRelease,
} |
Looks good to me |
5a2426a
to
c7dbf18
Compare
The code has been updated to reflect our discussed changes. |
What is the status of this PR? It works quite fine in most cases, but I believe the logic isn't quite right in some corner cases. Indeed, one does not want the one-shot to be released until an actual related effect is triggered but, currently, if I press a one shot mod, then a hold-tap key, then the modifier is released before the hold-tap key has a chance to resolve to either the tap or the hold action. In particular, in the case of a one-shot mod, there is no point in cancelling it before a key (or mouse) event is sent to host. For a one-shot layer toggle, the logic is quite correct though, since every key can be affected by a layer change, even if it is not supposed to resolve as a keyboard event. Maybe more fine-grained policies are required in the In this case, |
Sorry I don't have so much time on keyberon recently. But as this MR is closed, it's not in my priority list. |
I assumed something like this! So I will try to improve on it on my own and submit a new MR whenever I am done (unless @jtroo already addressed this in kanata-keyberon?). |
The code in kanata-keyberon does have some fixes and works reasonably well, but is suited mostly for the use cases of kanata. The code has diverged in many ways, again for use cases suiting kanata, making it more challenging to make PRs and contribute back - hence why I closed this PR. |
No description provided.