fix #101991 Ignore score command shortcuts in menus #5890
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Not shown here, but the build (actually the mtests part) failed on Travice CI, see https://travis-ci.org/github/musescore/MuseScore/jobs/668644613#L4430-L4433. Might just be a timeout though |
shoogle
added a commit
to shoogle/MuseScore
that referenced
this pull request
Apr 15, 2020
Previously, certain keyboard shortcuts were active in menus when they shouldn't be. For example, pressing the letter keys A to G while inside a menu would cause notes to be added to the score, and S would add a slur. This was problematic because letter keys are traditionally used to open menu items (e.g. pressing A in the Help menu should open the About dialog). This commit prevents unwanted edits from the menus by terminating the edit operation if the score does not have focus. The shortcut is still active, however, so this commit DOES NOT restore the traditional behaviour where pressing letter keys opens menu items. As such, this is a quick fix rather than a long-term solution. An investigation showed that a better solution is not possible without significant changes to the shortcut system. See description in PR musescore#5890 for commentary on various potential ways to solve this issue that were investigated and rejected in favor of this quick fix.
|
Travis still isn't happy, see https://travis-ci.org/github/musescore/MuseScore/jobs/675319311#L4405-L4411 |
shoogle
added a commit
to shoogle/MuseScore
that referenced
this pull request
Apr 15, 2020
Previously, certain keyboard shortcuts were active in menus when they shouldn't be. For example, pressing the letter keys A to G while inside a menu would cause notes to be added to the score, and S would add a slur. This was problematic because letter keys are traditionally used to open menu items (e.g. pressing A in the Help menu should open the About dialog). This commit prevents unwanted edits from the menus by terminating the edit operation if the score does not have focus. The shortcut is still active, however, so this commit DOES NOT restore the traditional behaviour where pressing letter keys opens menu items. As such, this is a quick fix rather than a long-term solution. An investigation showed that a better solution is not possible without significant changes to the shortcut system. See description in PR musescore#5890 for commentary on various potential ways to solve this issue that were investigated and rejected in favor of this quick fix.
|
And again... |
shoogle
added a commit
to shoogle/MuseScore
that referenced
this pull request
Apr 16, 2020
Previously, certain keyboard shortcuts were active in menus when they shouldn't be. For example, pressing the letter keys A to G while inside a menu would cause notes to be added to the score, and S would add a slur. This was problematic because letter keys are traditionally used to open menu items (e.g. pressing A in the Help menu should open the About dialog). This commit prevents unwanted edits from the menus by terminating the edit operation if the score does not have focus. The shortcut is still active, however, so this commit DOES NOT restore the traditional behaviour where pressing letter keys opens menu items. As such, this is a quick fix rather than a long-term solution. An investigation showed that a better solution is not possible without significant changes to the shortcut system. See description in PR musescore#5890 for commentary on various potential ways to solve this issue that were investigated and rejected in favor of this quick fix.
Previously, certain keyboard shortcuts were active in menus when they shouldn't be. For example, pressing the letter keys A to G while inside a menu would cause notes to be added to the score, and S would add a slur. This was problematic because letter keys are traditionally used to open menu items (e.g. pressing A in the Help menu should open the About dialog). This commit prevents unwanted edits from the menus by terminating the edit operation if the score does not have focus. The shortcut is still active, however, so this commit DOES NOT restore the traditional behaviour where pressing letter keys opens menu items. As such, this is a quick fix rather than a long-term solution. An investigation showed that a better solution is not possible without significant changes to the shortcut system. See description in PR musescore#5890 for commentary on various potential ways to solve this issue that were investigated and rejected in favor of this quick fix.
| @@ -5879,6 +5879,12 @@ void MuseScore::cmd(QAction* a) | |||
| tr("Command %1 not valid in current state").arg(cmdn)); | |||
| return; | |||
| } | |||
| if (sc->assignedWidget() == MsWidget::SCORE_TAB | |||
| && QApplication::focusWidget() | |||
There was a problem hiding this comment.
So this additional condition fixes the Travis mtest hang? Black Magic to me...
There was a problem hiding this comment.
I figured there might not be a widget that has focus during the tests since there's no GUI. It was just a guess though.
There was a problem hiding this comment.
An excellent one it seems, an 'educated guess' I'd say ;-)
igorkorsukov
approved these changes
Apr 17, 2020
anatoly-os
added a commit
that referenced
this pull request
Apr 20, 2020
This reverts commit 023b71f.
|
@shoogle I had to revert the changes since they broke note input: https://musescore.org/node/304164. |
shoogle
added a commit
to shoogle/MuseScore
that referenced
this pull request
Apr 23, 2020
Slightly better fix than originally attempted in PR musescore#5890. This time editing is terminated if the main window does not have focus, which means that it is safe to use toolbar buttons that take focus away from the score, such as the buttons for Voices 1 to 4. As with PR musescore#5890, these changes do not allow letter keys to open menu items. That would require substantial changes to the shortcut system as discussed in PR musescore#5890.
shoogle
added a commit
to shoogle/MuseScore
that referenced
this pull request
Apr 23, 2020
Slightly better fix than originally attempted in PR musescore#5890. This time editing is terminated if the main window does not have focus, which means that it is safe to use toolbar buttons that take focus away from the score, such as the buttons for Voices 1 to 4. As with PR musescore#5890, these changes do not allow letter keys to open menu items. That would require substantial changes to the shortcut system as discussed in PR musescore#5890.
This was referenced Apr 23, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves: https://musescore.org/en/node/101991
Previously, certain keyboard shortcuts were active in menus when they shouldn't be. For example, pressing the letter keys A to G while inside a menu would cause notes to be added to the score, and S would add a slur. This was problematic because letter keys are traditionally used to open menu items (e.g. pressing A in the Help menu should open the About dialog).
This commit prevents unwanted edits from the menus by terminating the edit operation if the score does not have focus. The shortcut is still active, however, so this commit DOES NOT restore the traditional behaviour where pressing letter keys opens menu items. As such, this is a quick fix rather than a long-term solution.
I investigated whether it would be possible to properly disable or override score shortcuts in the menus. I tried various methods:
Install event filters on the menubar, menus and submenus to accept all Qt::ShortcutOverride events. This worked in a bare-bones Qt project but not in MuseScore for some reason (shortcuts were triggered despite filters).
Change shortcut context from Qt::WidgetWithChildrenShortcut to the default Qt::WindowShortcut for all score actions. This worked to deactivate shortcuts in the menus, but it made them active in other parts of the program. For example, pressing Spacebar while on a checkbox in the Inspector would cause playback to begin (i.e. it didn't check the checkbox).
The ideal solution would probably combine these methods. I had some success changing the shortcut context to Qt::WindowShortcut and then filtering events on checkboxes and other widgets. However, this would require filtering events on every single widget that implements its own keypress handling, hence I decided to stick with the easy (albeit incomplete) fix for the time being.