Palette Search doesn't utilize Escape Shortcut as definable by the user

• Sep 26, 2019 - 22:52
Reported version
3.2
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project
Tags

1) Set the Escape shortcut to something like the grave character <`>

2) Utilize the Palette Search. To escape, using the 'grave' character won't do anything but it will type a grave character in the search box. The user must press the Escape key.

One could argue that it should be this way, but if so, notice that while typing in a Staff Text for instance, the user-defined custom escape shortcut is taken into consideration, and it will exit the text-box if, as with what was mentioned, the user presses the ` key.

This should be an easy fix. Although, if the user made the letter 'A' for instance as their escape key, that would be weird and rather naive, but still the program should honor its functionality while typing, even in a staff text/search box, and it should not bypass what the user explicitly set for the Escape function, which is openly available for customization in the Shortcut preferences.


Comments

Update: It appears upon a quick code glance that there is no taking into consideration the escape shortcut in the palette code, but instead, probably, the program is reliant upon some default Qt behavior to lose focus upon experiencing a Qt Escape key event. If this is true, all there needs to be done is handling a clearing of focus related to palette search box if it is in focus in the event.cpp file which does have a handler for the shortcut escape command, it appears. At least this is my first guess intuitively/logically.

I.E.: in MS 3.2.3 code:
events.cpp, line 881:
ScoreView::escapeCmd() {
case ViewState::NORMAL {

here use something like:

if MuseScore::getPaletteBox()::searchBox()::hasFocus() {
MuseScore::getPaletteBox()->clearFocus();
// here might need to set refocus to the score, not sure...
// there seems to be a function called focusScoreView(); that would probably work
// if it didn't focus appropriately afterwards. You'd think this wouldn't be necessary
// since the default Escape works fine after losing focus from the palette search box

}
else { // continue with the deselection process if there was no palette search focus
}

Don't have a MS compilation project up right now , but will hopefully soon to test. If anyone tests this idea, please leave a comment here.

Makes sense, but looking at 3.2.3 code won't really help here, the palettes were largely reimplemented for 3.3, so you need to look at master. Very possibly the relevant code would in a QML file somewhere.

In reply to by Marc Sabatella

In actuality, this is through looking at the master-branch code and I performed an error in typing it was version 3.2.3 since the behavior seen is coming from the program as version 3.2.3, but as for the code itself it was the master branch on github's site. Argh. Should try the beta out to double check its current activity.