Missing default keyboard shortcut for "Save as.."

• Feb 8, 2018 - 21:02
Type
Functional
Severity
S4 - Minor
Status
PR created
Regression
No
Workaround
No
Project
Tags

There is no default keyboard shortcut for "Save as.." in v2.2 and v3.0.
I would expext a default of CTR+SHIFT+S as in v2.0.


Comments

Severity
Status (old) active closed
Status active closed

It is possible to define this shortcut in preferences.

Severity
Status (old) active closed
Status active closed

Yes, of course. But there should be a default

Still, I can confirm that after a factory reset, my build of 2.2 shows the same issue. So something went wrong elsewhere (the above link is for master, but I can confirm shortcuts.xml for 2.2 doesn't show any obviously relevant changes either). Might be a Qt difference, as the shortcuts for "standard" commands like this are handled differently by Qt compared to our own shortcuts.

OK, then I guess it may have been a change elsewhere. Can anyone else confirm? Because of how this is handled, it might well be OS-dependent. I see the problem on Windows 10. I also get a warning, though, on startup (to the terminal, so only visible when starting from the command line), saying "Qt: Untested Windows version 10.0 detected", maybe that somehow gets in the way of it setting up the proper shortcuts. It appears we rely on Qt to tell us the standard OS shortcut based for Save As (as well as many other shortcuts) and somehow this isn't registering. If Qt can't tell us the standard OS shortcut for the command, we are stuck, and it appears that this is what is happening for some reason.

OpenSuse Leap 42.1

Distribution package of v2.1 is using QT 5.6.1 and the shortcut appears and works by default.
In the AppImage of as both v2.1 an v2.2 (both are using QT 5.4.2) the shortcut isn't available by default.

AppImage master (QT 5.9.3) the shortcut is available by default.

OK, I will try to investigate further. Does anyone know anything about the "Qt: Untested Windows version 10.0 detected" message? I mean, I can see from searching online that it is normal for a newer version of Windows to trigger this with an older version of Qt. My question is, could this be the cause of the problem - that Qt doesn't know the default shortcut to use? But then, it shouldn't have known in earlier versions either, and it worked before. So I do suspect it will turn out to be something about the fix for #235406: Regression: essential keyboard shortcuts missing.

And it doesn't work on Windows 7 either, this is known to Qt, only Windows 10 is not

Hmm, before that change _standardKey just got set. The change basically adds _action->setShortcuts(_standardKey); and if I get it right the 2nd part just takes care of displaying these standard shortcuts in the preferences dialog

You are correct, and tracing thre code, _action->setShortcuts(_standardKey) is getting called anyhow, in Shortcut::action(), later on during initialization. That is definitely happening here, I see it being called for save as:

https://github.com/musescore/MuseScore/blob/2.2/mscore/shortcut.cpp#L36…

But for some reason the call is failing, and I can't say why, because it returns void so there is no error code to check. All I know is, when we try retrieving the list of shrotcuts after calling setShortcuts(), it is coming up empty here:

https://github.com/musescore/MuseScore/blob/2.2/mscore/shortcut.cpp#L36…

This appears to be the only shortcut call that is failing.

Possibly related but probably not - all of the other standard shortcuts have flags of NONE, but this one is A_SCORE. It is also set to Qt::WindowShortcut but ordinary Save is not. Still, none of this is new, and changing it doesn't help.

Doh! I just realized it doesn't work for me in 2.1 either. I had defined a shortcut myself long ago I guess and forgot, but after a factory reset, I see it is gone.

So, I'm going with my hypothesis that Qt 5.4 just doesn't think there is an OS-defined default shortcut for save as on Window 10. And I think it may be right about that - I don't see any reference to one.

I suppose we could add a fall-back to the shortcut definition file, and alter our implementation to use the fallback if the initial attempt at installing the standard key fails.

It's an option, sure. I suppose the concern is that some OS we support might either have a different default their users would be accustomed to, or they might provide a way for users to customize that shortcut across applications and it would be good if we didn't ignore that. But in practice, I don't know if this actually happens - for all I know, it really is just Ctrl+Shift+S on all supported systems.