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

Chord management interface #2346

Open
Penguin-Guru opened this issue Sep 13, 2024 · 5 comments
Open

Chord management interface #2346

Penguin-Guru opened this issue Sep 13, 2024 · 5 comments

Comments

@Penguin-Guru
Copy link

Penguin-Guru commented Sep 13, 2024

This is a feature request and me sharing my thoughts for discussion on how it might be designed. I don't actually know much about the current macro language or software architecture, so there may well be things I've overlooked or misunderstood.

I would like to have a new section on the navbar for chord dictionaries. These dictionaries could be created and deleted, enabled and disabled, and imported and exported, like keymaps or macros. The way I imagine this working is that multiple dictionaries could be enabled at the same time, so users can organise their chords somewhat, but conflicts should be reported to the user and resolved by simply highlighting and ignoring earlier defined chords (higher in the same dictionary or in a higher listed dictionary) in favour of later defined ones. I imagine each dictionary consisting of:

  • A combination or sequence of keys that trigger the chord entry.
  • The resulting effect of the chord entry.
  • Any relevant settings, such as which keys in the chord must be combined, sequential, or either.

Despite this interface being designed for chords, I think it makes sense for the chord actions to essentially be any sort of macro action or sequence of actions. In the case of sequences of actions, it might be necessary to keep track of which are still executing and should perhaps block others. This sort of functionality could be added later. It might even be useful to have different types of dictionaries for text entry chords, dictionaries for other sorts of macros, and dictionaries that include both. These could be easily distinguished by a letter or symbol, in an effort to protect users who might blindly download and install large dictionaries of macros.

The user experience for handling conflicts is probably important to consider. Conflicts between active dictionaries should probably be detected during composition of new chord definitions.

I also think it would be useful to offer a simple mechanism by which to limit the scope of certain chord dictionaries to certain keymaps.

This sort of interface might also be useful for non-word-based applications, such as dictionaries of chords to enter unicode characters or emoji. For example...

  • Pressing both '+' and '-' together could produce a '±' symbol.
  • Holding Alt while pressing ':' and then ')' could produce a '🙂' emoji.
  • A user could press Alt, type the word "degree", and then press Alt again to input the '°' symbol.
  • Simultaneously pressing the 'u' and ':' keys could produce a 'ü' symbol.
@mhantsch
Copy link

I think you've captured some good use cases for chords, and why they should be easier to configure.

Forum discussion that deals with chords: https://forum.ultimatehackingkeyboard.com/t/chorded-escape-q-w-example-configuration-feature-brainstorming/1429

In addition to an implementation in Agent, this will need some firmware support.

@mondalaci
Copy link
Member

We won't implement a full-blown interface like suggested, but I plan to make chords easier to use via parametric smart macros, which I'll specify later.

@Penguin-Guru
Copy link
Author

Alright. I can't guess what that would look like so I will just look forward to seeing it. 🙂

Perhaps some day someone more invested in chording will have more thoughts to share. It does seem to be an increasingly popular topic.

@mhantsch
Copy link

I plan to make chords easier to use via parametric smart macros

Parametric smart macros may make some chords a little bit easier to configure, but not much. If you use any decent number of chords, you will still need many macros, esp. when for some chords the starting keys overlap. I really believe for a proper chording implementation you need a "chord list" (trie) somewhere in the firmware, processed before regular key processing, which activates either actions directly, or pushes virtual keypresses onto the postponer queue.

I suggest leaving the design to a later stage until it has mentally ripened (like good wine, some software design needs to age).

@Penguin-Guru
Copy link
Author

Penguin-Guru commented Sep 17, 2024

For context, I believe CharaChorder introduces new users with the 400 most common words. The actual number of words most serious users have installed is undoubtedly higher-- probably in the thousands. Some users will want to extend that to include things like unicode, emoji, and multiple languages (including syntax for programming languages).

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

No branches or pull requests

3 participants