Customizable hotkey system

[ZeroX-DG]

Current behavior

We need to provide a customizable hotkey system. This time we will need to plan out which hot key is for which command and where they should be stored to prevent confusion that the last Boostnote app created. Also while creating this system, we should create a hotkey validator to ensure hotkey input from user are valid so that we can prevent any problem that might cause by invalid hotkey. For example, this issue: https://github.com/BoostIO/Boostnote/issues/3501

Expected behavior

Have a section in setting page for customizing settings

---

IssueHunt Summary

Backers (Total: $0.00)

Submitted pull Requests

• #394 Hotkey Implementation

---

Become a backer now!

Or submit a pull request to get the deposits!

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

[issuehunt-oss[bot]]

@boostio has funded $30.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[oakypokey]

Got a lot of free time on my hands now, can I give this a shot?

[ZeroX-DG]

@oakypokey go for it mate :+1:

[oakypokey]

Currently, hotkey combinations are stored in browser/lib/ConfigManager.js. After going through the code, here is what I am proposing:

1. Hotkey patterns that only have one key are limited to [Ctrl, Alt, Option, Command]. This is to ensure that users do not assign a hotkey pattern to a single key that they may use frequently. For example, using M to hide and show the menu would not be helpful due to the fact that while typing, M will constantly show/hide the menu. These hotkeys will also only execute on release as they may be partial patterns for longer hotkey patterns.

2. Hotkey patterns cannot end in a modifier. For example Ctrl + Shift will not be valid as it could be considered a partial pattern of Ctrl + Shift + V. This will prevent unexpected behavior when trying to use Ctrl + Shift + V but accidentally triggering Ctrl + Shift. These patterns will execute on the down press of the final key as this is the design pattern for hotkeys.

3. Modifiers are [Ctrl, Alt, Shift, Super, Command, Option]

4. Validation will make sure that two commands do not share the same hotkey pattern.

5. If validation for one or multiple hotkey patterns fail, then the box which contains the pattern will be outlined in red.

6. In order to prevent user error, I think it will be better to have users to use the pattern that they will be using for the command. For example, instead of typing out Ctrl + Shift + V, users will actually press and hold Ctrl, then Shift, then V. The pattern will be saved when all keys are released. Whenever the hotkey pattern input box is in focus, pressing any modifier key will begin recording keystrokes.

7. Hotkey pattern validation failures should throw an error rather than returning false as it allows the application to pass more information to the user about what is actually wrong with their pattern. What's the policy around language support? I can add the English and French translations but what about other locales?

@ZeroX-DG are there any keys that should be blacklisted and do you have any comments on the above?

[ZeroX-DG]

@oakypokey I don't have any keys in mind that should be blacklisted. I like the idea that we start recording when modifier key is pressed, if we make it stop recording when a non-modifier key is pressed then we can ensure that the hotkey is always valid and therefore we don't even need a hotkey validator.

[oakypokey]

@ZeroX-DG I've created the tab and implemented the recording and saving system so it gets stored with the rest of the preferences-- is there someone who knows how to implement the actual hotkey actions so that they are registered and do something within the application / is that out of scope?

[arcturus140]

a blacklist sounds like a good idea. The question is, how extensive should it be?

i think an absolutely must should be:

1. generic hotkeys

example: ctrl + q : quit the application - usually not customizable, default behaviour esc alt + f4 : quit the application

2. desktop environment hotkeys

example: ctrl + alt + numpad : used by desktop environment super + arrow keys : used by desktop environment super + d : used by desktop environment

---

making restrictions on hotkeys is usually not a good idea, however since they cannot be customized on a system level it absolutely does not make sense to make any customizations on commonly used hotkeys. I am talking from my own experience.

[Rokt33r]

Ctrl + N and CTRL + T are not available in browser too. I think I should dig this more.

[arcturus140]

it is probably best to keep track of the default mapping for boost note with focus on platform compatibility, then let the user make adjustments at his own risk.

there is no way we can make assumptions on which hotkeys are "reserved" or not for the particular user.

It depends on the OS, the desktop environment, 3rd party background processes, keyboard layout, whether browser app or desktop app or android app is used, etc.

[oakypokey]

Even before that, I think it'd be a good idea to look at which actions will have a hotkey associated with them.

Also, in terms of handling, @Rokt33r mentioned mousetrap but after having a look at it I don't think it'll be easy to implement (I gave it a shot and it quickly turned into a mess). How does React-Shortcuts look? It seems to be aligned with what we're already using and I think it might be possible to have context specific shortcuts too if that was something we wanted to explore.

[Rokt33r]

@oakypokey Okay let's discuss a bit more in slack. I sent you a message in #dev-next channel of our slack.

[Rokt33r]

@arcturus140

it is probably best to keep track of the default mapping for boost note with focus on platform compatibility, then let the user make adjustments at his own risk.

there is no way we can make assumptions on which hotkeys are "reserved" or not for the particular user.

You made the point. We should let user to customize it and see how they are doing it. So I think the early stage of the shortcut customization doesn't need showing any error messages because I don't think we can cover all of them at once.

[issuehunt-oss[bot]]

@rokt33r has cancelled @boostio's funding for this issue.(Cancelled amount: $30.00) See it on IssueHunt

[Rokt33r]

Will rework this by myself.