"I" shortcut (Instruments dialog) no longer works as expected
Reported version
3.6
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
active
Regression
Yes
Workaround
Yes
Project
Version 3.6.2 / Windows 10
I had noticed this a little while ago, I don't think I've seen it reported. But this is a really unexpected behavior and it's really begin to annoy me!! :)
I.e. : the "I" shortcut (Instruments dialog) doesn't toggle between opening and closing as it always did before.
I guess it's a side effect of the addition of the search box above the Instruments list ? (I didn't search when it happened, but anyway, it's between 3.5.2 and 3.6).
See:
Comments
Works for me, I does toggle the Instruments dialog. At least as long as the search field doesn't have input focus, at which time indeed it does not and should not
3.5.2 behaves the same way (only there the search field is at the bottom)
As does 2.3.2
Did you take at least three seconds to watch my GIF?
So you can't say that it behaves in the same way between 3.5.2 and 3.6.
With 3.5.2, the shortcut toggle worked as expected, because you had to click specifically in the search box (located below Instruments list)
Now, since 3.6, as soon as you press I, the focus of the selection is automatically done in the search box. Hence a different behavior, once again, which I consider unexpected.
You can certainly quit with Escape (eg), but the "I" toggle, as it should be (same keystroke) remains by far the best.
For example: press "F8" shortcut (for Inspector opening). Is the selection focus is done automatically in the search box to choose a palette? Reply: no
So, inconsistent behavior.
I watched the gif start to end. And tried out the behavoir of 3.6.2, 3.5.2 and 2.3.2. They all behave the same, I toggles the instrument dialog, unless the search files has input focus.
But however, trying 3.6.2 now again, I see what you mean. I swear that wasn't the case an hour ago !?!
But it does as soon as you click the dialog somewhere outside that search field (and maybe that is what I fat-fingered before)
I can't see how that is Major though.
Esp. as the Instruments dialog has an OK and Cacel button (and Esc shortcut) to get out of it, it is in its whole natur very different from the palette (or Inspector).
Major, because it's a regression (and because there is still no other choice than "minor" and "major" - still no "normal"). But it's certainly not minor, again, it's a regression, and because the behaviors are inconsistent.
It is a Minor Regression, with several good and easy workarounds. Nothing major about it at all
And it is not even incosistent, as the palette, your example, is something entirely different.
It took me more than 10 years to learn that there is a toogle for this dialog...
"It took me more than 10 years to learn that there is a toogle for this dialog..."
??? 🙄
Last one: Do all common keyboard shortcuts F6/F8/F10 etc. and other "P" for the virtual piano close as expected when pressed a second time? Yes, they do.
Does the Instrument dialog "I" shortcut close after a second press, since the 3.6. No, it does not. It is something else. So, bad!
These are dialogs for different purposes, showhing/hiding Palettem, Selection filter, Mixer, Play panel and Inspector, which don't have an OK/Cancel button to get out of them, and all under Vuew, so entirely different from ther Intruments dia.log from the Edit menu. Nothing inconsistent there at all. The Preferences or Style dialogs don't toggle either...
Hmm, the file responsible for this should be ...mscore/instrwidget.ui or ...mscore/instrwizard.ui.
The former as per
git log
got last touched in 26d9649, November 2020 and as such is in 3.5 already. (but looks different there?!?)The later looks entirely different and is much older, last touched in df4aa9b61, November 2018 (might be dead code?)
What the hell is going on here?
Ah, no, it is listed to be in 3.5 Beta, but that seems entirely wrong, as 3.5.2 got released in October already. Seems a wrong tag in git / on Github.
So it indeed 26d9649 is the culprit change, the one that moved the search field from bottom left to the top left
"the one that moved the search field from bottom left to the top left"
Indeed, thanks. I was in the process of locating this change, and I was between the 11th and 17th of November at the moment.
git log
does help there, once you know which file to ask it for ;-)FWIW, for accessibiltiy reasons I'd prefer all dialogs that have a logical field in which to place keyboard focus would actually do this. To me, the only bug here is that the search box doesn't get focus the first time you open it. Esc is the supported way to close dialogs across all programs / operating systems.