Shortcuts need improved

• Nov 26, 2020 - 19:41
Reported version
4.x-dev
Type
Functional
Frequency
Once
Severity
S5 - Suggestion
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project

I've written this against 4.x development since it's not likely to end up in 3.6 with the eminent feature freeze. I'm calling it a suggestion since it doesn't work as well as it should but it works as designed.

Currently there are two ways to add a shortcut

  1. Open Edit->Preferences->Shortcut and add a shortcut to one of predefined actions.
  2. Create a plugin and apply a shortcut to it.

This has several limitations and potential problems. Listed in no particular order

  • Plugin shortcuts and predefined shortcuts are not aware of each other, so it's possible to assign the shortcut to two different actions. When this happens the action that will happen is rather unpredictable.

  • Predefined shortcuts may be applied to various contexts but the user cannot duplicate a shortcut in a different context if it already exists - explanation will follow

  • Predefined shortcuts are limited to Tablature, or non-tablature staves (drumsets are partly considered non-tablature staves) some shortcuts are the same everywhere and finally, some are usable inside of frames

  • finding an action for defining a shortcut can be challenging

Further discussion:

If the user assigns a single letter shortcut to a plugin, then while entering text into text elements, the letter may be entered or the plugin may be attempted to be run. This often results in the letter being simply ignored if the plugin does nothing while in text entry mode.

As alluded to earlier, plugin shortcuts and those in preferences are not aware of each other, so the user can assign the same shortcut to both a plugin and user definable shortcut in preferences. This will lead to unpredictable results.

Something good that happens is that you can define a shortcut for both tabular and standard note input such as the same shortcut for 256th note in both types of staves so there is already the ability to define context.

It is impossible to add a definable shortcut for text entry. There was recently a PR submitted that added shortcuts for note durations in text entry, this will make tempo entry easier. This cannot be user defined so it may lead to problems on some keyboards since e.g. ctrl+shift+4 is not like pressing the same keys even on US and GB keyboards.

In preferences it is possible to assign the shortcut ctrl+s; t (that is press ctrl+s then press t) to a user definable shortcut. The results will be unpredictable if the default ctrl+s is still defined and there will be no conflict reported. Sometimes pressing the combination will save the current score, sometimes it will perform the other action.

Drumset shortcuts are only active while in note input mode on a percussion staff with drumset defined as the sound. This is good so individual drums can be assigned a limited number of shortcuts. They are too limited in my opinion though

Suggested improvements:

Unify shortcuts so plugins and preferences are aware of each other and don't allow duplicates

Prevent single keystrokes (A, B, C...) from ever being considered a shortcut while in text entry. Always require ctrl or alt to be used for text entry shortcuts. Note: predefined shortcuts such as R work as expected, they duplicate the selection or repeat last note but are passed along as the letter r while in text entry mode. If single letters are going to be permitted for user defined shortcuts & plugins (which they should) they need to not be activated while in text entry mode.

Permit users to (re)define shortcuts used in text entry mode (such as permitting ctrl+shift+n for a natural sign).

Prevent contradicting shortcuts such as ctrl+s and ctrl+s; t as in my previous example.

Group shortcuts in a logical order rather than alphabetical or by shortcut only. Permitting sorting by shortcut is useful to me when looking for a new shortcut to add.


Comments

If you have a case where a plugin shortcut isn't detecting the standard shortcut, that's a regression in 4.0 perhaps - or a specific issue with a specific shortcut maybe. But in general, they are aware of each other. Can you give precise steps to reproduce this problem?

Overall, though, I agree there is room for improvement, and I fervently hope we can find a way to assign shortcuts to palette elements as well, so that's more context that needs to be dealt with.

The awareness of plugin shortcuts and those in preferences is new to me but the other things I mentioned are in need of improvement. For example, the single letter shortcuts being applied to a plugin are activated while typing text.