Improve Keybind/Hotkey Handling #5145
Comments
Tacodiva
added
the
status: needs triage
mxmou
added
type: enhancement
|
Wait, there's already an undocumented hotkey setting type? |
Yes there is, I'm pretty sure it's not even in the manifest schema validator, but it's there. |
|
Is this related to #4946? |
|
I think keyboard shortcuts and hotkeys should be implemented as a separate thing from settings (with its own property in the addon.json and own API that does things like fire events for keybinds), and keyboard shortcuts for vanilla elements would be be in a separate addon. |
|
In order to create a truly comprehensive hotkey addon API, we should also have a way to define target elements for the click action of a hotkey. For example, "Alt + Green Flag" would be defined as "Alt + click event on the CSS selector for the green flag". |
|
Another benefit of having a universal hotkey manager is that it could automatically check for hotkey conflicts (whether it be with the OS, the browser, Scratch, or another addon) and report that to developers. If we had an accurate database, this would make it easy to select a non-problematic hotkey. |
I'm sorry I misunderstood what you where saying- One possible option is have two hotkey settings, one with the + green flag and one without. This seems a bit unideal and it may be confusing why there's two hotkey options for the same thing. |
|
There could be a button alongside the regular hotkey input that has a "Click:" label to the left of it. We could do a text description on said button or even images. |
|
I'm not sure it makes sense to make a whole system for this when I can't think of any other button we would put there other than green flag and stop (even stop I'm not sure what you'd use it for). Another possible solution- we'll want to add support for binding multiple key combinations that map to the same setting anyways, maybe we could just have is so the first bind always has the '+ green flag' and the ones you add after that don't. I guess I just can't see why you would ever want to change the button it's bound to and it seems like a lot of additional complication to a UI already has the potential to be confusing. |
|
We wouldn't have to provide a way to change the button that "click" is bound to -- that would be unnecessary complication for the user. All I meant was that the "click" action should be defined by the addon and shown as an option. |
|
Sorry if this was mentioned before, but we should be able to set keybindings that use modifiers. |
Can you elaborate what you mean by "modifiers"? |
|
@Tacodude7729 Thanks for the writeup. I also think it's important to mention that addons should be able to reference a keybind action, so users can easily change keybinds that are related to specific addons, even if the keybind is handled by a different addon. I also wonder what would happen to that keybind if the "pause" addon is disabled. Would users still expect it to work? Would we disable the keybind? IMO, it should still work - but if the user accidentally pressed the keybind, they might not know how to unpause the project because there's no visible UI to unpause (probably not a serious problem, but worth thinking). |
|
@WorldLanguages It might be better to only allow addon hotkeys to be configured if the addon is enabled. |
|
Agreed -- if something is disabled in the settings, the user should be able to trust that it's disabled. |
In that case, if we decide to add a dedicated "hotkeys" section to the settings page that shows all supported keybinds, then we would need to either hide hotkeys that are currently unavailable because the addon is disabled. Or, alternatively, mark them as disabled and make it clear to the user why. Having keybinds that disappear might be a problem if we decide two separate actions can't have the same keybind. We would have to tell the user that the keybind can't be set because it's already used by another action, but we couldn't show which one. |
|
Why wouldn't we allow the user to set a keyboard shortcut that's currently used by an addon they never plan to use? |
Control, Alt and Shift |
I agree but this solution is problematic for the pause hotkeys specifically, as they should be in both the debugger and in the pause button plugin. A user may want to use the hotkeys with only the debugger or only the pause button enabled. Additionally, it would be confusing if a user was looking at the debugger and wanted to hotkey unpausing but the setting was actually under the pause button and vice versa. |
That's what I had in mind - some hotkeys are related to more than one addon at once.
Using pause hotkey as an example, I think we have two alternatives, each one with its own dropbacks:
Personally, I prefer option 2, and adding some type of UI notification in a corner that reads "project has been paused". An "undo" addon could possibly be added to the element, which unpauses the project when clicked. |
|
Note that what I just said would not apply for all types of keybinds. |
We also need to consider "gotchas" like this one. Building an architecture to support many different types of keybinds, while preserving an easy to use user-facing UI, is not going to be easy. Here's a non-comprehensive list of edge-cases and things to consider: (please tell me if there's more I haven't thought of)
|
|
It would be great to have a complete list of all vanilla Scratch keybinds. |
|
Just gonna point out that #4946 is related. |
As written in the initial issue, I thought there could be one big addon that contains all the keybinds for vanilla scratch functionality. Are you saying that you want all of these keybinds to be in separate addons? That seems like it's going to be way too many addons.
Where would the code for this go? The way I was thinking of implementing hotkeys as mentioned above would require the addons userscript to be ran to add the even listeners to the hotkey. |
ScratchAddons/manifest-schema#24 lol Also it's called the manifest schema, not the validator. |
Whoops, looks like we have 2 issues for the same thing, but discussion never started on the other issue. My bad! |
That's what I had in mind. But instead of using a "note", we could allow addons to reference keybinds which are technically handled by different addons, and the settings page would lie to the user and show it as part of the "wrong" addon(s). |
|
To summarize, this is what specifically is needed regarding hotkeys:
With these in mind, I think it will be a bit easier to develop a good solution. |
By developers, I assume you don't mean addon developers. SA should take care of conflicts, and this should be abstracted away from addon developers. |
|
I meant that when addons are initially created, the extension would be able to warn developers if the primary hotkey they chose conflicted with another addon's primary hotkey, one of vanilla's, or one of the browsers'/OSes'. Although it's a silly example, we wouldn't want everybody setting Ctrl+S as their hotkey because even though SA would abstract it away, it would then be pointless for most addons to set that as their primary hotkey. |
|
Right, I see what you mean. We need to ensure the default hotkeys, set by us, are usable in most platforms and coherent with every other hotkey. |
What does this invovle? Is there differences between keybindings on different OS/browser combos? I can't find any documentation for this. |
|
Some keyboard shortcuts are reserved by certain browsers and OSes. A fallback system would allow for alternate shortcuts to be automatically applied in these scenarios, without the need for the user to manually select one. |
|
I think the ideal would be adding an editor-hotkeys addon, and a website-hotkeys addon for vanilla functions and adding boxes empty by default to click and press a key to select like videogames do in other addons, with a warning if it's already used in the same place (editor, website, project, my stuff, messages, etc.) |
|
I think, to check the hotkeys, maybe we can press it using JS and check if it worked.
|
WorldLanguages
added
the
priority: 3
|
In comment #7532 (comment) I just proposed a first step towards letting users customize keybinds. Please do read it if you're interested. My suggestion targets only the following item mentioned in this issue:
And my suggestion builds on top of the existing addon architecture, so very few changes are needed, and there's no need to design any new UIs. |
As an open source project there are limited resources. I think this requires too much effort for the amount of help it provides to people. Each setting should just provide the option to pick the key (Which could perhaps be a standardised json option to reduce boilerplate). Anything beyond that is a waste of our time. |
I'm not too sure about the approach of creating a new addon which enables the hotkeys to be changed. While you're right it enables us to convey some information to the user, like it being beta/experimental and the details about two addons listening to the same key, I really don't think a new addon for this is an intuitive solution. To me, it makes a lot more sense for keybindings to be handled in scratch addons core. As a user, I wouldn't expect to have to enable a separate experimental "addon" to change the keybindings of a different addon. I don't really understand why you'd want the hotkeys to show up under a different addon instead of the one that the hotkey is actually effecting. |
|
Here are some additional reasons a decentralized solution (at least in the UI) is beneficial:
That said, I think it would be a reasonable choice to modify the keybind setting type (which should be created regardless of the solution chosen) to mirror its value to an always-enabled keybind "addon" hidden from the user. This would allow for duplicate keybind checking and other benefits of a centralized solution. |
|
I agree @lisa-wolfgang , but do we add a new addon foe changing Scratch hotkeys? |
|
If you think the "decentralized solution" is better, then go ahead with that. It's likely that I unconsciously believed there were reasons against it. I mean, it's the simplest and most straight forward way to add some customization, and we never added it, so I assumed we didn't want to. |
|
To clarify, what I had in mind is allowing users to change the keys for addons such as |
One advantage of a "centralized" option is that shortcuts for vanilla Scratch features could be customized in the same place. |
As I see it, currently, the way SA handles keybindings is not ideal.
The only real progress that has been made on this was the addition of the currently unused 'key' setting type in #793.
========================
Not sure if an issue is the best place to put this wall of text, but here we go.
I've put a bit of though into it and what follows is the solution I think would work best to mitigate all of these problems. It involves some substantial changes and contains a large amount of what I consider my personal opinion on how things should be done, so I want feedback before I try and actually do any of it. I also cannot do all of this by myself (I have no clue about vue.js 😅 ) so I would need some help.
The idea of keybinds as a setting is good but the current implementation has issues. Right now, when an addons uses
settings.get()on a 'key' setting, you get a string likeCtrl + Shift + F, for an addon to use this it has to be parsed then code has to be written to detect that keybind. Instead, for key settings,settings.get()should return an object that contains helpful things for implementing the keybind, such as an isPressed property, a way to get the keys in the bind without needing to parse a string and events that can be subscribed to for when the keybind is pressed and when it is released. I think this would have to be implemented through an additional script which gets injected to every page and listens for the keybinds of the addons that are enabled on that page. The 'key' settings also needs more options for constraining what types of keys can be bound to it.As well as these core changes, a new addon (maybe enabled by default) would need to be added for the keybind manager. This addon adds a new popup and tab which allows you to search keybinds from all addons by name or by the actual keybinding and change them from there (I'm thinking something like the keyboard shortcuts menu in vscode). It would also provide keybindings for vanilla scratch features that don't have one, so addons like 'duplicate scripts with alt key' or #705 could be put into this one. Keybinds should be mostly or all empty by default so loads of keybinds could be added without worrying about users having every key on their keyboard doing something they didn't set it to.
This addon could be split in two, one for the manager and another for providing keybinds for vanilla features but I'm not sure why you'd want one without the other.
Finally, I think the key setting appearing in the addons main settings should be optional (so these keybinds would only be visible in the manager). This will allow addons like devtools or the debugger to not have to clutter their settings section with 1,000 hotkey options. Obviously, all current addons which have keybindings should be moved over to the new system so their rebindable and play nice with the other addons.
This could be done in stages, firstly making the API better, than adding the manager UI, then moving all current addons over to the new system and finally adding keybinds for vanilla features into the manager.
The text was updated successfully, but these errors were encountered: