mirror of
https://github.com/BoostIO/BoostNote-App.git
synced 2026-04-26 21:05:55 +03:00
[GH-ISSUE #367] Customizable hotkey system #155
Labels
No labels
android 🤖
assigned to core 🦹
bug 🐛
documentation 📚
documentation 📚
duplicate 🚫
external issue 🔼
external issue 🔼
feature request 🌟
funded on issuehunt 💵
help wanted 🆘
improvement request 🔨
improvement request 🔨
ios 🍎
mobile 📱
needs investigation 🔬
needs more info ℹ️
needs specs 📐
plugin idea 🔌
plugin idea 🔌
poll 🗳️
pull-request
question ❓
rewarded on issuehunt 🎁
security issue 🔑
won’t fix ❌
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/BoostNote-App#155
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ZeroX-DG on GitHub (Feb 27, 2020).
Original GitHub issue: https://github.com/BoostIO/BoostNote-App/issues/367
Originally assigned to: @Rokt33r on GitHub.
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
Become a backer now!
Or submit a pull request to get the deposits!
Tips
@issuehunt-oss[bot] commented on GitHub (Mar 5, 2020):
@boostio has funded $30.00 to this issue.
@oakypokey commented on GitHub (Mar 17, 2020):
Got a lot of free time on my hands now, can I give this a shot?
@ZeroX-DG commented on GitHub (Mar 17, 2020):
@oakypokey go for it mate 👍
@oakypokey commented on GitHub (Mar 17, 2020):
Currently, hotkey combinations are stored in
browser/lib/ConfigManager.js. After going through the code, here is what I am proposing: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, usingMto hide and show the menu would not be helpful due to the fact that while typing,Mwill constantly show/hide the menu. These hotkeys will also only execute on release as they may be partial patterns for longer hotkey patterns.Hotkey patterns cannot end in a modifier. For example
Ctrl + Shiftwill not be valid as it could be considered a partial pattern ofCtrl + Shift + V. This will prevent unexpected behavior when trying to useCtrl + Shift + Vbut accidentally triggeringCtrl + Shift. These patterns will execute on the down press of the final key as this is the design pattern for hotkeys.Modifiers are [
Ctrl,Alt,Shift,Super,Command,Option]Validation will make sure that two commands do not share the same hotkey pattern.
If validation for one or multiple hotkey patterns fail, then the box which contains the pattern will be outlined in red.
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 holdCtrl, thenShift, thenV. 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.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 commented on GitHub (Mar 21, 2020):
@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 commented on GitHub (Mar 29, 2020):
@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 commented on GitHub (Apr 1, 2020):
a blacklist sounds like a good idea. The question is, how extensive should it be?
i think an absolutely must should be:
example:
ctrl + q : quit the application - usually not customizable, default behaviour
esc
alt + f4 : quit the application
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 commented on GitHub (Apr 2, 2020):
Ctrl + N and CTRL + T are not available in browser too. I think I should dig this more.
@arcturus140 commented on GitHub (Apr 2, 2020):
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 commented on GitHub (Apr 5, 2020):
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
mousetrapbut 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 commented on GitHub (Apr 5, 2020):
@oakypokey Okay let's discuss a bit more in slack. I sent you a message in #dev-next channel of our slack.
@Rokt33r commented on GitHub (Apr 5, 2020):
@arcturus140
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] commented on GitHub (Aug 25, 2021):
@rokt33r has cancelled @boostio's funding for this issue.(Cancelled amount: $30.00) See it on IssueHunt
@Rokt33r commented on GitHub (Aug 25, 2021):
Will rework this by myself.