Improve keyboard shortcuts, standardization, RSI preventability
Open, NormalPublic

Description

Description

Plasma is one of the most powerful desktop environments in terms of GUI settings and it allows to e.g. configure not only one but two sets of keyboard shortcuts per action.

However, such configurability depends heavily on organization and discoverability in order to improve User Experience; hence why System Settings required a redesign. Add to that the fact Plasma closely follows the paradigm of always showing keyboard shortcuts on its menus, thus making them discoverable, as mentioned before by @ngraham in his blog posts about UI design.

This redesign should also be done with keyboard shortcuts, which are numerous and whose defaults have been criticized in the past.

I propose an extensive re-evaluation of keyboard shortcuts used in Plasma by i) following RSI-preventive measures as much as possible, ii) using canon keyboard shortcuts whenever they make sense and iii) comparing keyboard shortcuts between applications, DEs and OSes, possibly creating a toggle to enable Windows, OSX, GNOME and i3 keyboard shortcuts quickly on Plasma.

One thing of note, however, is that while this proposed redesign takes heavily into account what users do and their experience with Plasma, this should NOT hinder the freedom of developers with regard to keyboard shortcuts. As is the nature of open source, such choices should be proposed, justified and decided in a colaborative manner, especially since developers are oftentimes also users of their own software.

How we know we succeeded

  • Users no longer complain about default keyboard shortcuts
  • Keyboard shortcuts are encouraged but not enforced and they are easy to find
  • It is easy to transition to Plasma in terms of keyboard shortcuts
  • RSI-prevention has been optimized
  • Keyboard shortcuts are consistent among KDE applications

Initial Guidelines

I believe academic reference materials have more prestige/authority for following RSI prevention, and one I'm particularly fond of (despite being relatively old) is this material provided by the University of Nebraska-Lincoln: http://rsi.unl.edu/
As such, I have devised some initial guidelines to follow in order to standardize keyboard shortcuts, as follows:

  • Using both hands to do a keyboard shortcut is preferable as it prevents RSI
  • Using only one hand is okay, but it shouldn't lead to excessive strain
  • The key combo should fit the position/format of the hand
  • If it's possible to make a combo with one hand, the maximum distance between keys should be no longer than between the pinky and the index OR no longer than between middle finger and thumb
  • The combo should be preferably a standardized one (Ctrl+C = copy);
  • If not standardized, it should have a semantic association (in Windows for instance, Win+E = Windows Explorer) or be semantically similar to other combos (Meta+Up and Meta+Down)
  • If not standardized or semantically pertinent, it must be physically close (Alt+Tab, Alt+' );
  • If not any of the above, it should at least be easy to memorize.
  • Arbitrary keyboard shortcuts with no reasoning behind them whatsoever should be avoided whenever possible.
  • The combo should preferably have two keystrokes to optimize the number of key presses while also not being accidentally activated
  • F1, F2, F3 and others can of course be used with one keystroke as they are physically distant from the "home row"
  • A modifier key like Meta can of course be used with one keystroke as well since it became standardized like so
  • If the key combo is used extensively in the desktop environment, it should follow the aforementioned combo rules (a good example is Alt+Space = krunner, which is one of the most powerful applications in KDE that is really easy and quick to get used to; in GNOME, for instance, setting Alt+Space for the command run dialog is not adequate because of how GNOME encourages usage of GNOME Overview)
  • If the key combo is barely used, it should have three or more keystrokes OR be physically distant, so only intermediate/advanced users would know about and access it
  • However, avoid three or more keystrokes whenever possible
  • Semantically, Ctrl should indicate control/management, Shift should indicate transfer/movement, Alt should indicate mode change/alternation
  • It is possible to establish semantic relations with the use of the physical placement/format of keys on the keyboard
  • It is impossible to completely avoid arbitrary combos, but it is possible to minimize their use

Tasks to be done in order to achieve this

I'll create a blog page elaborating on the use of various desktop environments and their correspondence to their respective keyboard shortcuts.

  1. Comparing different desktop environment standards

— Explanation of workspace dimensions: https://rabbiticlinux.wordpress.com/2019/10/13/fantastic-workspace-dimensions-and-their-limits/
This is relevant for the contextual analysis of keyboard shortcuts in each DE later on!

  1. Take into account the individuality and independence of developers with regard to how they want to implement keyboard shortcuts
  1. Decision-making regarding standards
  • Meta should have its semantics assigned to system/shell/global shortcuts, as decided by the VDG. Which currently existing key combos should be changed?
  • The vast majority of KWin keyboard shortcuts is actually not Alt, but Ctrl. Most notably those with the F1, F2 etc. keys. This is due to the high number of actions being activated with these keys, but maybe they could all be used with Meta?
  • ksmserver uses the standard combo Ctrl+Alt+key that is used in other DEs, such as Ctrl+Alt+L for locking the session. Should those be kept? I'd say yes.
  • Standardizing several KWin combos to Meta frees Ctrl+Alt+key combos, which can then be assigned to applications by users. Windows for instance allows for the creation of keyboard shortcuts to open applications, but the only combination that is safe to not conflict with Windows combos is Ctrl+Alt+key. On the other hand, some users prefer Meta for opening applications, such as Windows-based Meta+E and i3-based Meta+Return. I've also seen Reddit users switching Ctrl+Alt+T to Meta+T., including @jensreuterberg 's. Already standardized combos I believe should not be changed, but new ones can be added (as was the case of Meta+E). See this reddit post and this one for interesting usages. I've confirmed that Meta+first letter of application functionality is a standard in Xubuntu, which provides a consistent set of keyboard shortcuts.
  • Are tray combos (Alt+D,S for instance) considered shell shortcuts?
  • GNOME's plans also include setting Meta as a system keyboard shortcut. It's in their HIG, more specifically those of Florian Müllner in the comment section.
  • Should tray combos (e.g. Alt+D,S) be changed/removed?
  • These combos are broken and not immediately clear to average users. It seems to work in a sort of emacs-ish way as well, which does not occur anywhere else in Plasma.
  • There's is currently no way to navigate between panel and tray widgets. This is possible on GNOME via Ctrl+Alt+Tab (terrible combo, great functionality IMO). If there were a way to navigate through them (e.g. a single combo activates the first widget in the tray, the rest can be navigated with mouse or Tab), there is no need for keyboard shortcuts for each widget. If this cannot be implemented, then having functional combos for tray widgets would be the solution. Otherwise, these Alt+key+key combos can be removed altogether, as they do not work correctly or are unneeded given users themselves can set global shortcuts for them.
  • Set of functionalities to consider in-full: window tiling, window navigation, window movement, virtual desktop movement, window-to-virtual-desktop movement
  • Should all of them use arrow keys? If not, should some?
  • Semantic role of Ctrl, Shift, Alt and Meta should be discussed first.

ARROW MODIFIERS

ACTIONMETAMETA+CTRLMETA+SHIFTMETA+ALTMETA+CTRL+ALTMETA+CTRL+SHIFT
Snap WindowsX
Switch Focus between WindowsX
Move Window between ScreensMETA+SHIFTMETA+CTRL+ALTMETA+CTRL+SHIFT
Switch to VDX
Move Window to VDMETA+SHIFTMETA+CTRL+ALTMETA+CTRL+SHIFT

PAGEUP/PAGEDOWN MODIFIERS

ACTIONMETAMETA+CTRLMETA+SHIFTMETA+ALTMETA+CTRL+ALTMETA+CTRL+SHIFT
ACTIONMETAMETA+CTRLMETA+SHIFTMETA+ALTMETA+CTRL+ALTMETA+CTRL+SHIFT
ACTIONMETAMETA+CTRLMETA+SHIFTMETA+ALTMETA+CTRL+ALTMETA+CTRL+SHIFT
ACTIONMETAMETA+CTRLMETA+SHIFTMETA+ALTMETA+CTRL+ALTMETA+CTRL+SHIFT
ACTIONMETAMETA+CTRLMETA+SHIFTMETA+ALTMETA+CTRL+ALTMETA+CTRL+SHIFT
ACTIONMETAMETA+CTRLMETA+SHIFTMETA+ALTMETA+CTRL+ALTMETA+CTRL+SHIFT
ACTIONMETAMETA+CTRLMETA+SHIFTMETA+ALTMETA+CTRL+ALTMETA+CTRL+SHIFT
ACTIONMETAMETA+CTRLMETA+SHIFTMETA+ALTMETA+CTRL+ALTMETA+CTRL+SHIFT

CHARACTER MODIFIERS

CHARACTERACTIONMETACTRL+ALT
EDolphinX
.EmojiX
TKonsoleX
PKScreen2X
DShow DesktopX
QActivity SwitcherX
CHARACTERACTIONMETACTRL+ALT
CHARACTERACTIONMETACTRL+ALT
CHARACTERACTIONMETACTRL+ALT
CHARACTERACTIONMETACTRL+ALT
  • Set of functionalities to consider in-full: accessibility
  • Should a specific modifier key or combo be associated with accessibility options? For instance, GNOME uses Meta+Alt for all its accessibility features.
  • Could window snapping in the corners (upper left, bottom left, upper right, bottom right) be bound to some modifier plus Home, End, PageUp and PageDown?
  • (placeholder)
  1. Evaluating each application
  • (placeholder)
  • (placeholder)
  • (placeholder)
  • (placeholder)
  1. Applying such changes

Relevant links

http://rsi.unl.edu/
http://www.tifaq.org/articles/keyboard_retraining-junjul99-kahan&griffin.html
https://pointieststick.com/2018/12/18/on-headerbars/
https://pointieststick.com/2019/03/06/more-on-headerbars-rebuttals/
https://wiki.gnome.org/Design/OS/KeyboardShortcuts

  1. After full evaluation, propose a partial or complete set of standards to XDG
  • Meta for system shortcuts? (requires task 1 to be fully done)
  • Alt+F1 to F4?

I am willing to put work into this

I am interested

add your name
thiagosueto updated the task description. (Show Details)Sep 7 2019, 4:19 PM
thiagosueto updated the task description. (Show Details)Sep 7 2019, 5:01 PM
thiagosueto removed a project: Goal Setting 2019.
thiagosueto updated the task description. (Show Details)Sep 19 2019, 1:52 PM

Howdy,

i m all in with this. Keyboard shortcuts an navigation is one of the most basic parts for accessibility and power users. I will do some investigation here and come back with hopefully something useful.

ndavis added a subscriber: ndavis.Sep 22 2019, 8:10 PM
thiagosueto updated the task description. (Show Details)Sep 26 2019, 3:07 PM
thiagosueto added a subscriber: jensreuterberg.

One thing I'd very much like to see is a formal agreed upon document on xdg mailing list that states:

"these modifiers combos are for apps to use in their defaults"
"these modifiers combos are for desktops to use in their defaults"

Right now it's very easy to get conflicts and apps that don't behave well with each other. Then people just point fingers without having any sort of basis to dictate who should change.

That needs to happen at a much broader level than KDE.

[panel focus] If this cannot be implemented

It can. It's a bit complex, as you have to toggle window flags about claiming focus, but it's do-able.

then having functional combos for tray widgets would be the solution.

FYI, this exists, but only the launcher has a default set.

One thing I'd very much like to see is a formal agreed upon document on xdg mailing list that states:

"these modifiers combos are for apps to use in their defaults"
"these modifiers combos are for desktops to use in their defaults"

Right now it's very easy to get conflicts and apps that don't behave well with each other. Then people just point fingers without having any sort of basis to dictate who should change.

That needs to happen at a much broader level than KDE.

Agreed. I think it could be feasible to get some agreement that the Meta key should be for the DE and is off-limits to apps, which use the Ctrl and Alt keys instead. This is generally what apps and DEs do already so hopefully formalizing it won't be too controversial.

romangg triaged this task as Normal priority.Oct 3 2019, 11:37 AM
romangg updated the task description. (Show Details)
romangg added a subscriber: romangg.
romangg updated the task description. (Show Details)Oct 3 2019, 11:40 AM
thiagosueto updated the task description. (Show Details)Oct 3 2019, 2:01 PM

I changed the terminology used in the task to Meta instead of Super and kept Virtual Desktop instead of Workspace, but that's for consistency sake. Meta/Win/Super are synonymous, Virtual Desktops and Workspaces are as well.

I agree, keyboard shortcut decisions should also be done on a much broader level, and proposing changes to XDG is a great idea, but I think this should be done after checking other DEs. It's likely there are things that most DEs do the same that could be proposed, but I haven't actually seen evidence (yet) that most DEs use Meta for system/shell functionality, despite this being my impression as well. I know that GNOME and i3 sort of do this, I'm not certain about other DEs, and compiling a list with all keyboard shortcuts of all DEs was my plan anyway.

This Saturday I'll (hopefully) release two blog posts elaborating on virtual desktops and GNOME. It's easier to do so for me since it's my take/analysis and it might be rather opinionated, in addition to not flooding this task, which will certainly get very long.

What I said here is also relevant to this task. I also agree with @graesslin 's point of not breaking userspace, and I think their take on this should be insightful too.

chempfling added a comment.EditedOct 4 2019, 10:35 AM

In case of UI accessibility i know that the following terms are true and most importaint for basic keyboard only navigation:

  • all combinatins with META are made for "global scope" like window manager, desktop environment and such.
  • Alt + XXX combinations are used for the menu bar of the current application
  • Tab: brings the user to the next Element
  • Shift + Tab: brings the user to the previouse element
  • Ctrl + Tab: brings the user to the next Panel ( logical group of widgets)
  • Ctrl + Shift + Tab brings the user to the prviouse Panel ( logical group of widgets)
  • Arrow keys: bring the focus to the next element in the arrow direction
  • Return: activates current element (like leftclick on current focused element)
  • Spacebar: activates current element (like leftclick on current focused element)
  • Shift+ Arrow: mark entries in direction
  • Ctrl + Spacebar: select entries with cherrypicking (hold Ctrl to navigate around and not lose the current selection; navigation without hold Ctrl removes selection)
  • F10: focus/ (on some systems also opens ) the menubar of the current application
  • Shift + F10: opens context menu (like rightclick on current focused element) - not every keyboard has an "menu key" thats why this is an alternative -> special laptops
  • ESC: stop current activity
  • F7: Toggles an Caret on / off -> Textcursor
  • F1: Open Help
  • F2: Rename / edit
  • F3: Search
  • Alt + F4: Close current application
  • Ctrl + Q: Close current application (in multi tap applications)
  • Ctrl + F4: Close current Tab (in multi tap applications)
  • Ctrl + W: Close current Tab (in multi tap applications)
  • F5: Refresh
  • F11: Fullscreen / Window Mode Toggle
  • Pos1: focus first element
  • End: focus last element
  • Picture up/ down: move all the screen up / down
  • Ctrl + Picture up/ down: go to next tab.
  • Ctrl + Shift + Picture up / down: go to previous tab

i hope this helps a little. this is spoken with accessibility lens and default on most desktops. But it provides the most importaint stuff to make the user interactable with its computer not using the mouse.
I know of. Sounds basic, but some of them are not clear to everyone i know and its very needed :).

some of them could be found in our new Accessibility HIG, thanks to @fabianr
https://hig.kde.org/accessibility/checklist.html

maybe missing stuff could be added if required.

Quite interesting stuff! I did not know about Ctrl+Space, F7, F10, Shift+F10, Ctrl+F4, Ctrl+Shift+PictureUp/Down.

I also did not know that Pos1 = Home and Picture Up/Down = PageUp/PageDown.

One thing I noticed is that Ctrl+F4 conflicts with Plasma's default "Switch to Desktop 4". It's a non-issue if Ctrl+W exists, though.

chempfling added a comment.EditedOct 4 2019, 9:35 PM

Quite interesting stuff! I did not know about Ctrl+Space, F7, F10, Shift+F10, Ctrl+F4, Ctrl+Shift+PictureUp/Down.

I also did not know that Pos1 = Home and Picture Up/Down = PageUp/PageDown.

One thing I noticed is that Ctrl+F4 conflicts with Plasma's default "Switch to Desktop 4". It's a non-issue if Ctrl+W exists, though.

glad that i can help :). you can ask me everything about accessibility. its not my main dish, but my girlfriend is blind. so i have to struggle a lot with those kind of stuff. i created an own CLI screenreader ("fenrir") for her needs.
if we can make this shortcuts consistent and functional its a big win for power users (guys like me, who like the keyboard) and accessibility as well (for last is a must have to provide basic interaction with UI).

like I already noted, I'm all in for this :).
if i can do something or provide information about that, let me know.

By the way, thanks for pick this up :)!

thiagosueto updated the task description. (Show Details)Oct 13 2019, 5:53 AM
thiagosueto updated the task description. (Show Details)EditedOct 21 2019, 5:05 AM

I finished the blog post describing GNOME keyboard shortcuts, please have a read; this should be particularly insightful to those who never used GNOME.

In addition, it also seems that GNOME plans to use Meta for system shortcuts.

thiagosueto updated the task description. (Show Details)Oct 21 2019, 5:14 AM
chempfling updated the task description. (Show Details)Oct 21 2019, 1:37 PM
thiagosueto updated the task description. (Show Details)Nov 10 2019, 9:15 PM
hase added a subscriber: hase.Nov 11 2019, 4:04 AM

I firmly believe we need a keyboard shortcut for switching windows between screens; after having checked on GNOME (which is heavily based on workspace switching), I felt the lack of such a keyboard shortcut when checking on XFCE.
I think the apropriate modifier for that would be ?+Shift+Right/Left since it's transfer/movement, however I'm not sure about the first modifier, whether it should be Ctrl or Meta.

Can someone verify keyboard shortcuts on Windows/OSX? I have no access to a Mac whatsoever (they are literally 5 times more overpriced in my country) and Windows would take way more time because as I understand several DEs use keyboard shortcuts from it. I didn't include them on the list but it would be nice to have those for comparison.

This week I should also have a list of keyboard shortcuts and/or config files with keyboard shortcuts for the DEs that were already analized (and Plasma's kglobalshortcutsrc). I was thinking of putting this information on a spreadsheet table which would then be kept inside a github repo. Is there something from the KDE infrastructure that would allow for easy editing of spreadsheets I can put this in?

ognarb added a subscriber: ognarb.Nov 18 2019, 1:42 PM

I don't have a macbook anymore (rip) but one of the fundamental difference between mac and linux in term of shortcut is the use of a cmd button (located directly left from the space button) instead of the ctrl button. So using cmd+c instead of ctrl+c.

When I still used my macbook I switched virtual desktop by swiping with 3 fingers to the left or right. According to the internet there is also the possibility to use ctrl+left arrow or ctrl+right arrow to move between desktop but I never used it.

In general macOS had a very good touchpad based gestures and depending on how many fingers were involved, this would invoke different actions. This made me use a lot less keyboard shortcuts than then I use plasma. Here is a video how this work: https://www.youtube.com/watch?v=OPpZVZNzeyc

Maybe @ngraham can add more information about how keyboard shortcut work in macOS :)

If you need to store files and share them, take a look at https://share.kde.org ;) you should be able to log with your KDE Identity information.

Added T10573 as a subtask because it includes pertinent discussion about workspace navigation.
Added T12068 as a subtask because if workspaces are merged with Activities, this affects default keyboard shortcuts as well.
Added T8434 as a subtask because it seemed pertinent if we are to organize keyboard shortcuts in the Global Shortcuts KCM accordingly.

Am I correct in assuming that subtasks must be resolved as steps before the main task can be resolved?

thiagosueto updated the task description. (Show Details)Nov 23 2019, 11:18 PM
thiagosueto updated the task description. (Show Details)Dec 4 2019, 7:59 PM

Pretty much.

thiagosueto updated the task description. (Show Details)Dec 15 2019, 1:40 PM
thiagosueto updated the task description. (Show Details)Dec 15 2019, 1:52 PM
thiagosueto updated the task description. (Show Details)Dec 15 2019, 2:02 PM

Okay, since default shortcut to switch to VD was already chosen, we only need to figure out the rest of the navigation shortcuts.
It was taking a while because we had to decide which modifier goes with Meta, but if one of the set has already been decided, the rest goes along quickly.
So for navigation we just need "Move Window between Screens" and "Move Window to VD". I find the first to be absolutely needed here.

thiagosueto updated the task description. (Show Details)Dec 16 2019, 2:38 AM
thiagosueto updated the task description. (Show Details)Jan 13 2020, 2:51 AM

Okay, I think aside from Windows and OSX, we already have most major DEs and keyboard-driven environments here, and it's been a while since we had input from other people. Part 1 of section Tasks to be done in order to achieve this is already quite significant. I'll continue working on that, but that does not hinder discussion here, to be clear.

Part 2 is not a task per se, but something to consider while discussing.

Part 3, Decision-making regarding standards, is where we discuss stuff. Primarily, what do you think of each point in this section? Do you have any other suggestions? Do you agree/disagree with something? Please be very critical and if possible provide feedback. I'll add it to the task description for easier reference later.

romangg updated the task description. (Show Details)Jan 13 2020, 6:12 PM
romangg removed a subscriber: romangg.

Could window snapping in the corners (upper left, bottom left, upper right, bottom right) be bound to some modifier plus Home, End, PageUp and PageDown?

My current setup for moving windows around:
Ctrl+Num0 walks window from monitor to monitor
Ctrl+Num[2,4,6,8] moves window to side of current monitor
Ctrl+Num[1,3,7,9] moves window to corner of current monitor
Ctrl+Num5 moves window to center of current monitor

This is the setup I have been using for a few years, and seems to work quite well. I expect most would argue for using Meta instead of Ctrl though. :)

Plasma doesn't actually have a command to move window to corner without resizing as yet - I've been trying to work on that myself: https://bugs.kde.org/show_bug.cgi?id=418015
Unfortunately I have run into issues with building the source that we can't seem to figure out, so my work has kind of stalled on that.

I'd like to propose that there be added a default shortcut to restart plasmashell and/or kwin - essentially a "uh oh, things are weird/broken" command.

Reasoning:

  • I have personally had plasmashell break repeatedly since returning to the Linux world these past few months, things like the panel getting stuck half in/half out of edit mode, widgets half resized/half colored in, crazy pixelated artifacts, even all of the plasmashell just disappearing (a crash I presume). Ideally these things would not happen, or if they did then recover automatically - however this isn't quite the case reliably. I've seen these issues across several distros from debian, ubuntu, kde neon, opensuse, manjaro... A simple plasmashell --replace was able to recover things nicely.
  • I have often seen instances of others with issues in IRC/Matrix, reddit, distro forums whose advise in similar situations was "restart plasmashell", sometimes as a complete fix and often as a troubleshooting step - this definitely seems to be of use to people.
  • I envision a scenario where I convinced my friend to try Linux and set him up with KDE, or I set up a system for my mother to use - if I receive a text that says "The panel is stuck half in the edit mode" or something similar, telling them to open krunner/terminal and do plasmashell --replace is both awkward, and not really acceptable for anyone not technically inclined. Telling them however to press a key combo is simple, and easy to remember if they have an issue again in the future. This is the kind of simple approach I would feel comfortable telling a client to try in a business setting.

The shortcut should probably be at least 3 keys, so that it isn't used accidentally. Users are already familiar with similar ones such as Ctrl+Alt+Delete, which most Windows users know as an "uh oh" shortcut. I also recall Ctrl+Alt+Backspace being used to restart the X server in a similar fashion (though not sure if that is used still these days).

With this default shortcut in place a user having issues could be told simply "Do [HOTKEY] to restart your GUI without losing your open applications" - being a simple hotkey rather than a command, they'd be likely to remember and use it again in the future without further assistance.

I don't particularly see any issue with creating a keyboard shortcut for restarting Plasma as long as it's very hard to press, so either a 3- or a 4-key combo. I directed merrit to ask here so the community can voice their opinions on this.
SDDM for instance already proposes a loginctl unlock-session command in case something goes wrong with it, so a fallback plan (though in a different context) isn't unheard of in Plasma.
The only issue with such an implementation would the hypothetical setup of plasmashell --replace in combination with kwin_x11 --replace, which would make such a keyboard shortcut more complex to set up since users might be on Wayland and kwin_wayland does not have a --replace flag and thus cannot be restarted without logging out. If possible, however, this would work better than a mere plasmashell --replace.

We have fallbacks and auto recovery for when things are detected to have gone wrong. Putting in pre-emptive workarounds for the user to activate is unprecedented.

It seems like a very very lazy solution to fixing problems properly that promotes bad practice.

If the global shortcut to launch KSysGuard were made independent of Plasma and KWin, that might help. Right now, when you need it most, the shortcut won't work because one or both of those will be down.

Like David, I also woudn't be in favor of a global "restart plasmashell+kwin" keyboard shortcut. It does seem lazy. We need to fix these problems, not promote working around them.

Would that even work on wayland? I guess not if KWin hangs...