Skip to content
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

Closed
wants to merge 1 commit into from
Closed

Conversation

jtroo
Copy link
Contributor

@jtroo jtroo commented Jul 15, 2022

No description provided.

@jtroo
Copy link
Contributor Author

jtroo commented Jul 15, 2022

This is for #62

@jtroo
Copy link
Contributor Author

jtroo commented Jul 15, 2022

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.

@jtroo
Copy link
Contributor Author

jtroo commented Jul 15, 2022

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.

src/action.rs Outdated Show resolved Hide resolved
@TeXitoi
Copy link
Owner

TeXitoi commented Aug 1, 2022

Maybe the release of the one shot should be at the first not one shot release, allowing to:

  • one shot Ctrl
  • press alt
  • press suppr

Or maybe not? (it might cause one shot shift + rowling not doing the intented behavior).

@jtroo
Copy link
Contributor Author

jtroo commented Aug 1, 2022

Maybe the release of the one shot should be at the first not one shot release

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:

  • one shot ends only when a press that is not a one shot key happens

@TeXitoi
Copy link
Owner

TeXitoi commented Aug 1, 2022

What's the behavior in QMK and ZMK? If that's it for the 2, I'm OK with it.

@jtroo
Copy link
Contributor Author

jtroo commented Aug 1, 2022

From reading the documentation:

  • QMK doesn't advertise combining multiple one shot mods (though it supports it according to chaining one shot mods qmk/qmk_firmware#2796)
  • ZMK allows combining multiple sticky keys
  • ZMK allows configuring if a press or release ends its sticky keys (quick-release) setting via quick-release
    • It probably wouldn't be too hard to add this, so may as well

@TeXitoi
Copy link
Owner

TeXitoi commented Aug 1, 2022

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,
}

@jtroo
Copy link
Contributor Author

jtroo commented Aug 1, 2022

Looks good to me

@jtroo jtroo force-pushed the one-shot branch 2 times, most recently from 5a2426a to c7dbf18 Compare August 1, 2022 23:59
@jtroo jtroo requested a review from TeXitoi August 2, 2022 00:04
@jtroo
Copy link
Contributor Author

jtroo commented Aug 2, 2022

The code has been updated to reflect our discussed changes.

@jtroo jtroo closed this Feb 18, 2023
@jtroo jtroo deleted the one-shot branch February 18, 2023 09:58
@ald0o
Copy link

ald0o commented Sep 24, 2023

What is the status of this PR?
I pulled the code and I am currently using it.

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.
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 tap or hold action.

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 OneShot struct? (we need both a field for the press versus release policy and a field for the "all event" versus "side-effect events only" policy).

In this case, Custom actions also need a field to say whether they have side effects, since it cannot be guessed.

@TeXitoi
Copy link
Owner

TeXitoi commented Sep 24, 2023

Sorry I don't have so much time on keyberon recently. But as this MR is closed, it's not in my priority list.

@ald0o
Copy link

ald0o commented Sep 24, 2023

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?).

@jtroo
Copy link
Contributor Author

jtroo commented Sep 24, 2023

@ald0o

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants