While currently there are no keyboard shortcuts that are limited to just one context, I agree that it'll be a useful improvement in the future. I can imagine some use cases for such feature. Maybe shortcuts that are limited to just the note list, or the notebook list, or some shortcuts specific to WYSIWYG or just one editor.
Just checking if shortcuts are unique isn't enough in this case. It would be useful to reuse the keyboard shortcut that is only available in the note list, somewhere else in the application. I think we can fix this by checking if the shortcuts are unique within their own context.
I suggest the following data structure for the shortcuts:
{ accelerator: 'Control+N', command: 'newNoteItem', context: 'default' }
Using this structure, we can specify a shortcut limited to note list: select all menu as following:
{ accelerator: 'Control+Shift+M', command: 'moveToNotebook', context: 'noteListSelectAll' }
If something like this is implemented in the future, while it is a different context than default, keyboard shortcuts in the default context should still be enabled. (Just my opinion) Otherwise user has to "exit" the current context to use their familiar shortcuts. Shortcuts of default context are, quote, unquote, "Global shortcuts" throughout the application.
We should be able to reuse the above shortcut in some other context:
{ accelerator: 'Control+Shift+M', command: 'newNotebook', context: 'sidebar' }
In conclusion, a shortcut is duplicate if:
Context is default, and it's already used
Context is not default, but it's already used in default context
It's not a duplicate if:
Context is default, and it's not already used
Context is not default, and it's not used in default context (but maybe in some other context)
Moved conversation:
There is an issue with detecting duplicates according to the context.
Correct me if I’m wrong, but I couldn’t find any shortcuts (or menu commands) that will be disabled or enabled, or have their action changed depending on what the user is focused on. So all shortcuts are enabled, at all times.
For example, even if the user is focused on the note list, “Bold” command is still enabled. Therefore I’m having trouble figuring out how it’d be compatible.
To de-duplicate we have the context - so Ctrl+A means selecting all notes in the note list, or selecting all text in the text editor. I believe that’s the Source column in your mockup?
As for the shortcuts being enabled/disabled, it’s up to the component to handle this at the moment. For example, formatting shortcuts are disabled when only the note viewer is visible.
The question was should we allow duplicate keyboard shortcuts for actions if for example, one of them is only allowed in note list, and the other one is only allowed in note body.
Both of those actions are presented as one action: “Select all” to the user. There’s only one shortcut associated with it. This is about two different actions.
If the user is focused on note body, all keyboard shortcuts are enabled and usable as per my understanding. This makes having the same keyboard shortcut for any two or more distinct actions impossible in any other case.
Moreover, I think it’s better to only allow an unique keyboard shortcut for each action as a user experience measure. But that’s just my opinion.
Source was actually just an indicator for the user to see if they’ve changed the shortcut or it’s still the default. It was just an alternative suggestion. For example, it’d say “Default” if user hasn’t changed it, and “User” if he/she has. I was suggesting it as an alternate to just show commands whose shortcuts have been changed in italics and others in regular text.
My understanding about shortcut context was, since they’re already handled well with menu items (“Select all” meaning two different things, menu items automatically disabled when unavailable, etc.) we wouldn’t need to pay special attention to that area in the keyboard shortcut editor.
The issue is to whether we should allow two different shortcuts for two different actions, and disambiguate based on the context? If that’s the question then yes that should be allowed.
But on the other hand there’s no context column in the mockup so I’m not sure what’s the status of it? I guess it’s whatever is logical: if the primary key is the shortcut, then there can’t be twice the same shortcut. If the primary key is shortcut/context then there can be twice the same shortcut.
I think we should go with unique shortcuts for each action, mainly because Joplin doesn’t have a lot of shortcuts. Another benefit is the user don’t have to change the focus beforehand executing a keyboard shortcut.
As I was saying, currently all shortcuts are enabled when the user is editing the note body. That’s why I didn’t include a context field in the mock-ups. (Even if I did, then it’d be “Default” for everything…) Therefore having context-limited shortcuts are not useful at the moment, in my humble opinion.
I agree it’s not currently useful but it feels like the kind of thing that would be hard to add back later on, while it’s relatively easy now. But maybe I’m missing something.
What would be useful is to see your current data structure for the shortcuts, actions, etc. as that would inform what we can support or not. In fact, you should maybe have a separate post for this where you keep it up-to-date based on your discussions with Tessus and me?