FEATURE: Use Ctrl+Shift+, as the standard keyboard shortcut to invoke KDE programs' "Configure <Program>" menu items.
- Group Reviewers
- R237:cd25475f8723: Use Ctrl+Shift+, as the standard shortcut for "Configure <Program>"
This shortcut is not used by anything else. Searched on lxr, found one conflict in DigiKam, and the developers agreed to change it: https://bugs.kde.org/show_bug.cgi?id=386335
Will wait to land this until Digikam 5.8.0 is released to prevent any shortcut conflicts.
Tested in KDE Neon. Tried out Plasma, KWin, Dolphin, Kate, Konsole, Gwenview, Okular, Konversation, KTorrent, and Skanlite; all now have a consistent keyboard shortcut for their "Configure <Program>" menu items.
In KDevelop, this is also a really important shortcut for navigating through the source. Ctrl+, for jumping to definition, Ctrl+. for jumping to declaration. /me wonders if one really needs a shortcut for configuring shortcuts at all.
https://lxr.kde.org/search?_filestring=&_string=Qt%3A%3ACTRL.*Qt%3A%3AKey_Comma lists the usages (=> Digikam, KDevelop, KMail)
The muscle memory for Mac users isn't preserved, as the keystroke there is command-, not control, and command physically corresponds to Alt. So this only gets us a relatively new Windows shortcut, on top of the legacy CUA system. I have no idea whether Windows still follows CUA or not.
As we're a CUA-derived UI, we already have a keyboard shortcut for Configure Shortcuts: Alt-s Alt-h. Same for Configure $app: Alt-s Alt-c
While I do find switching back and forth between Mac and CUA intermittently frustrating, we really can't easily implement the same suite of keystrokes as Mac because of the Alt combinations being reserved for menus.
do you really find yourself opening the app settings that offen that you need a shortcut?
I personally don't think adding this shortcut makes sense, the preferences is not something you invoke usually, i.e. like Ctrl+C, Ctrl+V
Your original patch had some value trying to cater for the macOs refugees, but now that isn't even the case, i have to ask, why "steal" from apps one more shortcut?
I do find myself doing this a lot, yes. I know a lot of people who, upon downloading a new piece of software, the first thing they do is check out the preferences window to see what's available. It's a subtle thing, but throughout the macOS world where the shortcut is consistent across all apps, people do in fact open the Preferences windows a lot. With a consistent shortcut, it's practically a zero-effort operation. In platforms without that, the mental and physical effort is greater, so they don't open the Preferences window as much.
Ctrl-Alt-, is way outside of anything I would expect as a common shortcut. Did you try Alt-,? I have no idea whether it'd work or not, but the odds of having a menu whose name begins with (or even contains) a comma are low.
Alt+, is definitely better, yeah. Also, now we are actually preserving recovering Mac users' muscle memory, since the Alt key on a PC keyboard is in the same place as the Command key on a Mac keyboard.
Since @ngraham added me as reviewer, here are my 2 cents. Trying the patch, I made those observations:
- Alt often is released by the user only after the dialog is shown already, resulting in the (normally hidden) accelerators ("_") of the dialog showing and then dissappearing, which looks odd.
- Normally Alt is used either for accessing the menu itself or in combination with the cursor/navigation keys, but not so much for shortcuts. While there are exceptions, at least our shortcuts for executing standard actions affecting all apps should IMHO stick to Ctrl.
- Does not work in Kontact and KMail (but does work in KOrganizer and KMail's "New Mail" window).
Note I don't oppose the idea to have a universal shortcut for opening the preferences, but I feel that with the currently selected shortcut the net effect to the overall user experience and consistency is slightly negative.
I won't block this patch, but instead let me add this ideas:
- The patch is not really urgent. Do we have the chance to gather some telemetry data on the usage of shortcuts as well as on the preferences dialog? That way we could better evaluate the usefulness and maybe even choose non-conflicting shortcuts.
- Apply the change only via a shortcut theme package for Mac refugees (not sure if can we have such a thing?)
- If we change it at all, this should get in very early in the cycle to judge how much this conflicts with custom shortcuts users have.
Just checked: It's already there in Standard Shortcuts, where it can be changed.
Well, it says Configure System Settings…, so I even discarded this when first looking for it. As a soon-to-be shortcut expert, do you see a chance this could be changed to Configure Application… (only in System Settings, of course)?
Changed to Ctrl+Alt+, because Alt-only shortcuts are weird
Still feels a bit awkward and has the Alt accelerator problem. Maybe something involving Ctrl+⇧? (← that's a "Shift")
Definitely, that bugs me too. Now to figure out where exactly this is set...
Yeah that's probably for the Best. Too bad Ctrl+Shift+, doesn't work only because Digikam is using it. I'll to find something else.
That would work, and it's not taken, but I worry that this wouldn't help a lot of users, because outside of seasoned Linux users, Meta isn't a well known description for the Windows/super/Command key (depending on the keyboard hardware).
Is there any other menu action which has Meta in its shortcut? If not, this might be an indication that we are heading in the wrong direction. I find Meta more appropriate for global shortcuts (virtual desktops, activities, window management, Kickoff, …), where it is already used. Do we have a HIG regarding this, so we maintain at least some order and logic?
We don't seem to have anything against it. My only request is that if we do shortcuts, make them use 2 hands instead of just one. If the keys are too close together, this makes it harder to enter. Possibly harder for people with disabilities as well. So, space the sets in 2, one on the left side of the keyboard and the next symbol on the right.
Well, that's more of a list than a well-explained guideline. This is quite good (grep for "system reserved shortcuts", but also see general reasoning): https://developer.gnome.org/hig/stable/keyboard-input.html.en
So as for changing the name...
I notice that this uses QT_TRANSLATE_NOOP3() instead of i18n. It seems that the English string at least is simply a bad translation, likely caused by the poorly-chosen base string, which I've changed to be a bit more descriptive. I've never done any translation work before; can anyone give me a super-quick primer on how to submit a better string here?
Was confused and it took me a while to figure out how this will end up for different keyboard layouts. Turns out using the KCM combines ⇧+key, while arc patch results in all three keys shown in the menu.
This means that . is always used, regardless of keyboard layout. As this key is quite important for writing, it should be easy to access almost everywhere.
Great find, I like it :) (and it even fulfills @abetts' demands for two hands). Let's hope nobody finds any obscure place where this is used already...
can anyone give me a super-quick primer on how to submit a better string here?
Last time we summoned @ilic it worked out well, otherwise do some API docs reading?
Hm, conflicts in Konsole. However, can we change Konsole? At least, you could use this to improve your lxr search, so maybe more is found (bad) or Konsole is the only place (not quite as bad).
If we need to change one app, we could also target Digikam, which is as far as I can tell the only one using Ctrl+Shift+,
Actually the problem is that this string--whatever it is in the code--is being changed for English to "Configure System Settings..." when viewed in System Settings > Shortcuts > Standard Shortcuts:
I haven't been able to find where that's being done. Also, is it a problem that this is using QT_TRANSLATE_NOOP3() instead of i18n()?
Is it, though? I don't see it here:
There might actually be a bug here: Adapting your patch to Ctrl+⇧+,, I get this for Digikam:
- warning on startup
- Configure Digikam works
- Zoom to 100% works
- shortcuts listed as Ctrl+⇧+, and Ctrl+,
Possibly the conflict detection is broken?
Turns out it's not, the shortcut is actually defined for the "Light Table". However, there the shortcut is listed twice and works the same (for me at least). Might be worth talking to Digikam if this is an oversight or what is going on there.
As mentioned in the bug, we should wait until after digiKam has had a release containing the change, i.e. 5.8.0. Provoking the dreaded shortcut warning dialog would be a bad way to say "thank you". Roadmap and NEWS say the release was planned for 2017-10-29, but it is still not tagged. We can wait a couple of days, otherwise I assume Frameworks 5.41 (or later, no need to rush) would fit better.
That said, more reviewers looking for potential additional conflicts would still be appreciated.