#412 Change Keyboard Shortcuts (with GUI)

[Anonymous]

I searched in multiple places (included this feature request area) for a way to change keyboard shortcuts.

I know in the old version of Rosegarden, you could quickly and easily change a huge variety of keyboard shortcuts.
And I loved how your could filter keyboard shortcuts, by searching for their names.

But the new version of Rosegarden does not seem to have ANY menu for changing keyboard shortcuts.

Therefore, my primary feature request is a simple way to change the keyboard shortcuts in Rosegarden.

My secondary feature request, is to re-implement the ability to filter shortcuts by name, that tool was great!

[Philip Leishman]

Oh right - I didn't think of that case - clearing all shortcuts from an action.
Thanks.

[Ted Felix]

Working great now. I have some ideas that might make it easier to use. Hopefully they are easy to implement. I will gather them and post soon.

[Ted Felix]

Ok, here are three of my ideas.

• Add a QDialogButtonBox at the bottom with Ok/Cancel to make it easier to save or cancel changes.
• If changes have been made, display a message box after Ok that says a restart of Rosegarden is required before shortcut changes will take effect.
• Add a "Clear Shortcuts" button (like Reset to Defaults) to make it easy to clear all the shortcuts for an action/row.

.
I think if we can get these in, we're ready to merge. I have more ideas, but they are icing on this already really useful cake, so I'll save them for later.

[Philip Leishman]

OK I have implemented your suggestions. The message box comes when the editor is closed if changes have been made.
I also took account of the application wide shortcuts.
I think I am about finished with this.
Ideas and bugs welcome.

[Philip Leishman]

One other point - The shortcuts should not be translated in the rosegarden ts files. Qt provides translations - see toString(QKeySequence::NativeText).

[Ted Felix]

Looks good. Just one thing... I don't see Ok/Cancel buttons (QDialogButtonBox) at the bottom. Am I missing a commit, or was that not easy to implement?

[Philip Leishman]

There are OK and Cancel buttons in the warn dialog. If you mean the main ShortcutDialog - this has no buttons - it is an editor for the shortcuts and a cancel button doesn't make much sense there. The notation and matrix editors don't have these buttons either.

[Ted Felix]

ShortcutDialog is indeed where I'd like to see Ok and Cancel. These are configuration preferences, not the document that the user is editing. All of our preferences dialogs have ok/cancel/apply. That would be helpful with shortcuts as well (though apply is useless if the changes aren't reflected immediately, so just ok/cancel for shortcuts). Cancel would be particularly helpful if someone became wrapped around the axle making changes then wanting to toss them.

[Philip Leishman]

OK. It wasn't so difficult. OK and Cancel are there.
Anything else ?
It might be nice if some other experienced users tool a look at this !

[Ted Felix]

This is working really well.

I've posted the beginnings of a test plan on the wiki:

https://www.rosegardenmusic.com/wiki/test:shortcut_editor

I'm going to go through and make the text/instructions consistent with the rest of rg, then I'm going to merge this and get it into the user's hands.

I have a bunch of ideas, but it will be interesting to see what the users suggest. They might have some better ideas. Let's plan on a discussion period (maybe a week or two after the announce?) before making further changes. Don't want to go on a wild goose chase then have to redo everything when a better idea comes along.

[Ted Felix]

Merged as [fb9c6f]. Please test latest git.

Let's wait 'til March 7 and revisit this based on feedback received on the user list along with my idea list.

[Yves Guillemot]

Thanks Philip.
It's a really important feature which was lacking for years.

At first I had some trouble understanding how to use the dialog, but after some times it works great. Here are the beginner's problems I encountered :

• The second field defined a second shortcurt. It's not the place where the shortcut replacing the first one have to be entered.

• Selecting a shortcut and pressing delete doesn't only delete the shortcut, but defines the "delete" key as the new shortcut!

Well, it was my fault: all is clearly explained at the top of the dialog, but I didn't read it immediately.
Maybe should a red bold title "How to use this dialog" be added?

I understand that this is a preliminary code. So maybe some of the following remarks are not relevant:

• Should not this dialog be a new entry of "Edit -> Preferences..." rather that
  "Edit -> Keyboard Shortcuts..."?

• Pressing the return key in the filter field closes the dialog.
  I inadvertantly do it several times. It would be better to ignore this key here.

• The shortcuts list show icons without any action name (mainly in notation)

• Several actions share the same name (e.g. there is six "Ti" actions in notation)
  This issue comes from the definition of the notation menus, not from the shortcut dialog.

• Shortcuts are no more translated
  It may be annoying when entering notes with keyboard.
  With an AZERTY keyboard and the French translation, typing AZER with a C major key entered C4 D4 E4 F4. Now it enters C3 C2 E4 F4.
  Of course, the shortcut dialog allows the user to change it, but this is no more an out of the box configuration coming with the translation.

Here is a suggestion about the last issue:
Using the translation to assign the keys was never perfect because you may want to use some translation while using a non standard keyboard (foreign keyboard, dvorak, etc...).
So it would be fine to have a library of mapping files for non QWERTY keyboards that could be loaded before applying the shortcuts editor mapping.

[Ted Felix]

Should not this dialog be a new entry of "Edit -> Preferences..." rather that
"Edit -> Keyboard Shortcuts..."?

Many programs have it as a separate item in the edit menu. E.g. The GIMP. I think it's ok either way. It's probably easier this way for Rosegarden so that we don't have to integrate with the Preferences dialogs.

[Ted Felix]

Well, it was my fault: all is clearly explained at the top of the dialog, but I didn't read it immediately. Maybe should a red bold title "How to use this dialog" be added?

Actually, I have a number of recommendations for improving this dialog that might make it easier to use and reduce the need for instructions. We are pausing work on this until tomorrow to see if we get any feedback from the user list. So far, nothing. So, I'm going to put together my suggestions tomorrow and post them. Then hopefully Philip will have time to look at all of this.

[Philip Leishman]

Thanks for your suggestions Yves.
I will wait for the post from Ted and then consider all the suggestions !

[Ted Felix]

To get an idea of how other app's shortcut editors work, I surveyed the shortcut dialogs in three apps: Inkscape, the GIMP, and Eclipse.

All three agreed on the following:

• Shortcuts should be set the moment they are entered. There should not be a "Set Shortcuts" button. I've been tripped up by this, forgetting to press "Set Shortcuts" and then leaving the dialog.

• Only one shortcut should be allowed per action. Ours should display multiple in the list (if they exist), but only allow the user to specify exactly one via a single QKeyEditSequence widget. That one user-specified shortcut will cause all other shortcuts for that action to be removed.

There were some differences of opinion on the following points, but I think it's pretty clear which way we should head...

• Inkscape and the GIMP allow for editing the shortcuts "in place". You click on the cell where the current shortcut is displayed in the list and that cell becomes a QKeySequenceEdit (or equivalent) where the user can enter the new shortcut. QItemDelegate appears to be the key to providing a custom editor for a cell in a list. Should be interesting and hopefully not too difficult.

• Handling of conflicts was very different in the three apps I surveyed. Inkscape just automatically removed the shortcut from the conflicting action without telling you. The GIMP popped up a messagebox with the conflicting action and asked if you wanted to Cancel or "Reassign Shortcut". So, same as Inkscape, but with the option to Cancel. Eclipse just shows you the conflicts in a list on the main action list dialog, marks them with a "C" in the action list, and lets the user deal with them. I think for us, the GIMP approach is probably best. This is similar to what we have now, but simplified. Instead of allowing a decision on each shortcut, just make it all (Reassign) or nothing (Cancel).

I have some other minor suggestions as well, but I think the above will have the biggest impact on usability.

[Philip Leishman]

Comments from Yves:

1. Should not this dialog be a new entry of "Edit -> Preferences..." rather than
   "Edit -> Keyboard Shortcuts..."?

I think having a separate menu item and not integrating into preferences is OK

1. Pressing the return key in the filter field closes the dialog.

This appears to be a default for QDialog. From the Qt documentation: "A dialog's default button is the button that's pressed when the user presses Enter (Return)."

I can look into changing this.

1. The shortcuts list show icons without any action name (mainly in notation)

Yes a lot of actions which are just in toolbars are defined without text. Of course they have a name but this is only a keyword not really a descriptive text.

Two options:
a) Actually define a text for all actions in the rc files
b) If no text is defined use the action name (with translation)

1. Several actions share the same name (e.g. there is six "Ti" actions in notation)

This appears to be a bug. I will look into it.

1. Shortcuts are no more translated

Yes. I thought this dialog would make this unnecessary. The idea of providing presets for different keyboards may help here.

Comments from Ted

1. Shortcuts should be set the moment they are entered.

OK - I will look into removing the set shortcuts button.

1. Only one shortcut should be allowed per action.

Hmm.. In the rc files there are up to 4 shortcuts. I have no problem in reducing to one but then I think we should only have one shortcut in the rc files. If we allow multiple shortcuts it should be the same in both places.

1. Inkscape and the GIMP allow for editing the shortcuts "in place".

Yes this would be neater. I will look int this.

1. Handling of conflicts

Maybe the approach I started with is too complex. So just show the confilicts and allow accept (removing the shortcut from other actions) or cancel.

I will look into all these ideas!
Thanks

[Philip Leishman]

The numbers above are all 1 (cut and paste problem) - Sorry
so the points are
1. Should not this dialog be a new entry of "Edit -> Preferences..."
2. Pressing the return key in the filter field closes the dialog.
3. The shortcuts list show icons without any action name (mainly in notation)
4. Several actions share the same name (e.g. there is six "Ti" actions in notation)
5. Shortcuts are not translated
6. Shortcuts should be set the moment they are entered.
7. Only one shortcut should be allowed per action.
8. Editing the shortcuts "in place".
9. Handling of conflicts

To 4 above I thought I was losing some of the text but this is not the case. There are six actions involved (just looking at notation). Here is a list with the action text and it's translation:

Action	Text	Translation
insert_6_flat	VII/ti flat	Ti
insert_6	VII/ti	Ti
insert_6_flat_high	VII/ti flat	Ti
insert_6_high	VII/ti	Ti
insert_6_flat_low	VII/ti flat	Ti
insert_6_low	VII/ti	Ti

So we end up with 6 "Ti"s in notation.
The Text entries are unfortunately not distinct and the translations are even worse !!
Not sure who is responsible for the translation to American English ;)

The shortcut editor is showing up some problems in the rc and translation files !

Suggestions ?

[Philip Leishman]

So I have made a first attempt at points 6 and 8 above (never used that delegate stuff before).
There may still be some bugs but I have made a merge request. Please test.
Oh - one bug - it is no longer possible to set the escape key as a shortcut. Escape cancels the editing. This can be fixed by subclassing the QTreeView.
Comments welcome

[Philip Leishman]

Fixed the escape problem - no subclass of QTreeView. It goes in the eventFilter of the delegate.
Also for problem 3 above I have used the action name (translated in the QObject context) if no text is provided.

[Ted Felix]

Only one shortcut should be allowed per action.

Hmm.. In the rc files there are up to 4 shortcuts. I have no problem in reducing to one but then I think we should only have one shortcut in the rc files. If we allow multiple shortcuts it should be the same in both places.

Sounds good. A quick analysis: Multiple shortcuts are only used for a handful of things...

The ancient Shift+Ins, Shift+Del, Ctrl+Ins, copy/paste commands. I think we can definitely drop those and only support Ctrl+C/Ctrl+X/Ctrl+V. Since we have a shortcut editor, users can put this back if they are really attached.

Matrix and Tempo View Delete allows Ctrl+D and Del. I think Del is good enough.

Media keys for stop, media previous, etc... I can't get the media keys to work, so I think we can safely drop support for them. If someone complains, we can figure out how they got them to work and proceed from there. Plus we have support for MIDI controller transport buttons, so we should be able to convince them to switch to that.

Play has Enter (which doesn't work since that launches an editor), Ctrl+Return (which appears to be meaningless?) and Ctrl+Enter. I think this can be safely reduced to Ctrl+Enter.

So, yeah, I agree with you. Let's reduce the number of shortcuts per action to one, then reduce the number of shortcut columns in the editor to one as well.

[Chris Cannam]

Play has Enter (which doesn't work since that launches an editor), Ctrl+Return (which appears to be meaningless?) and Ctrl+Enter. I think this can be safely reduced to Ctrl+Enter.

Enter is the key at bottom-right of the numpad, if you have one. Return is the key you are perhaps thinking of as Enter. All three shortcuts make some sense once you know this, and they do all work.

The original Play shortcut in RG was Enter, i.e. the numpad key. It was copied from Logic. It's quite handy if you have a full-size keyboard but useless if you lack a numpad, so we later added Ctrl+Return (as Return had already been allocated to launching editors and Space to arming the record function) to give laptop users something they could actually use.

Ctrl+Enter was probably added just so that anyone who got the two shortcuts mixed up wouldn't be disappointed, rather than with any expectation of anyone using it. It's ironic that this is the only one that now appears on the tooltip.

A similar situation possibly inspired Ctrl+D for delete, since some keyboards (notably Mac ones) lack Del, although it can always be produced with Fn+backspace.

The cut and paste shortcuts using Ins/Del were the original Windows standards. I wonder how many people even remember them.

I can't remember anything relevant about the media keys.

[Ted Felix]

Thanks for the history lesson, Chris.

So it sounds like Play only needs Enter and Ctrl+Return.

Once we do that in the .rc file, we could reduce the number of shortcut columns to 2. Seems like a reasonable compromise.

[Ted Felix]

Finished testing. There's one new bug that appears related to the conflict dialog. After selecting all the set and reset buttons on the conflict dialog and clicking ok, the new shortcut appears as the first, but the remaining shortcuts are shifted to the right. The new shortcut should replace the old with no shifting.

For example, if I have "Enter, Media Play, Ctrl+Return, Ctrl+Enter" for the play action, and I try to set "Space" as the first shortcut, go through the conflict dialog and say that I really want to do that (press the set button), I end up with "Space, Enter, Media Play, Ctrl+Return".

I should end up with "Space, Media Play, Ctrl+Return, Ctrl+Enter".