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.

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.

In T11520#202515, @davidedmundson wrote:

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.

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.

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.

In T11520#203532, @thiagosueto wrote:

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 :)!

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.

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?

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?

Pretty much.

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.

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.

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...

In T11520#203511, @chempfling wrote:

• Alt + XXX combinations are used for the menu bar of the current application

Firefox or Thunderbird use Alt+M.
Ctrl + M is used in most KDE applications to display/hide a menu bar, though at least Konsole differs here with Ctrl+Shift+M.

I have started a thread on the XDG mailing list that is relevant to this task:

https://lists.freedesktop.org/archives/xdg/2020-May/014298.html

Noah Davis:

Hello, KDE is currently trying to standardize on reserving the Meta/Super/Start/Command key for global/desktop environment shortcuts.
It seems to me that it would be in the interest of every desktop environment to standardize on this in order to prevent global/shell shortcuts from conflicting with Linux apps.
For instance, Alt + Left Click is an old shortcut for dragging windows around that is still used by KWin, but it conflicts with Blender, GIMP, Inkscape and Krita.
Many creative workflow apps need modifier+mouse button shortcuts to be fast and easy to use and apps generally avoid using Meta/Super already.

Any thoughts?

In T11520#225277, @alexde wrote:

In T11520#203511, @chempfling wrote:

• Alt + XXX combinations are used for the menu bar of the current application

Firefox or Thunderbird use Alt+M.
Ctrl + M is used in most KDE applications to display/hide a menu bar, though at least Konsole differs here with Ctrl+Shift+M.

Oh sorry, I was not clear enough. I dont talk about display/ hide the menu bar but interact with the content of the menu bar.
Like just pressing "Alt" (on windows, gnome uses something different whyever i think it was "F10" AFAIK) should just focus menu bars first child menu (but dont open it) and Shortcuts like "ALT + e" should open a menu i.E. _e_dit and focus its first entry.

like this:
_f_ile | _e_dit | _h_elp

• just pressing Alt should focus but not open _f_ile menu (from an accessibility point of view its required do be able to explore the menu with arrow keys, because i.e. blind people dont know what menus are even exist in the menu bar)
• pressing an combination like "Alt + h" should focus and open help menu