SUMMARY Changing key combination for action "Move to Trash" in System Settings app causes Delete key to not work in text fields and text editors in many Qt apps. After changing the key combination Delete key does nothing, but the newly-assigned key works as Delete (i.e. deletes character in front of cursor). STEPS TO REPRODUCE 1. Open System Settings application and go to Workspace > Shortcuts > Shortcuts > Common actions > File 2. Find and expand "Move to Trash" action 3. Uncheck "Del" under "Default shortcut" 4. Click "Add custom shortcut" and press F12 key 5. Click "Apply" OBSERVED RESULT Immediately after clicking "Apply" Delete key stops working in the "Search..." text field at the top of the System Settings window and F12 works instead of it. After logging out and logging in the issue appears in other applications as well (tested in Kickoff, KRunner, Dolphin). EXPECTED RESULT Changing key combination for "Move to Trash" should not affect which key is used to delete a character in front of cursor in text fields. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE neon 5.20 User Edition (neon-user-20201119-0945.iso) KDE Plasma Version: 5.20.3 KDE Frameworks Version: 5.75.0 Qt Version: 5.15.1 I initially found this issue in my openSUSE Tumbleweed system and later reproduced it in a VM running KDE neon. ADDITIONAL INFORMATION I think that the problem is in KdePlatformTheme::keyBindings() . In the following line it returns KStandardShortcut::MoveToTrash shortcut for QKeySequence::Delete: https://github.com/KDE/plasma-integration/blob/00fc43a2b71a421395e10b0cee8e67a09e398fe9/src/platformtheme/kdeplatformtheme.cpp#L262 The description of QKeySequence::Delete in Qt documentation is not very specific, but Qt itself uses it in implementation of text fields to determine which key should delete character in front of cursor. For example, here: https://github.com/qt/qtbase/blob/e4961b35deb202525d4711dbb14f8c2bb0bf5c26/src/widgets/widgets/qwidgettextcontrol.cpp#L1325
Oh dear, that explanation seems quite plausible, yes. :( Unfortunately reverting that change would break the fix for Bug 426573. Not sure how to proceed.
I do not think that QKeySequence::Delete means "Delete a file" in Qt. I think it means only "Delete a character". The Ctrl+D combination comes from here: https://github.com/qt/qtbase/blob/e4961b35deb202525d4711dbb14f8c2bb0bf5c26/src/gui/kernel/qplatformtheme.cpp#L197 The comment says it is from Emacs. I think that the correct fix for bug 426573 should be replacing use of StandardKey.Delete with something else, because i think StandardKey.Delete is not about deleting files.
That seems reasonable, but we use the QKeySequence::<whatever> chars all over the place throughout Plasma on the asumption that our QPA will translate them through our KStandardShortcut system. Perhaps this basic design is flawed and needs to be re-thought. Eike, could you comment?
As a temporary work around, should we temporarily disable the ability to change shortcuts for the action "Move to trash"? Having the delete key stop working for editting text fields is far more annoying then not being able to change a pretty reasonable default shortcut for trashing files.
*** Bug 469449 has been marked as a duplicate of this bug. ***
CCing. THIS is why "delete" has very frustratingly not done text-delete for me for ages (since kde3 era I believe, certainly it was broken in kde/plasma5 and remains broken on 6, but not sure about 4)! Being an old-timer even the confirm-on-delete is a luxury and I just learned to be careful, tho I still find delete-confirmation a useful luxury so enable it where possible. But trash?! Bah-humbug! It just gets in the way of actually freeing the space I wanted free or I'd not be deleting the file in the first place! Unfortunately, kde/dolphin doesn't appear to allow actually disabling trash, but it's set to the smallest possible size (0.01%, ~2MB on my 20 gig /home) and time (24 hours), warn-on-full, which means a warning (I've gotten one in ~20 years!) if I mistakenly trash instead of delete a file over 2MB, (hopefully) delete with a llloonnggg latency of a 24 hours if it's under that. Meanwhile, the unused trash functionality shortcut is disabled, and delete is configured to do what it says on the label -- delete (albeit with confirmation). Now I find out that having delete configured to actually do what it says on the label (the key is NOT labeled "trash"!) for files is unintuitively killing the other normal delete-key functionality, text-deletion! =:^( At least now I can go digging in the source to see about changing the default shortcuts so delete actually does what it says on the label without me having to customize the shortcut, thus triggering this bug...
There is a very simple workaround for this bug, at least for Dolphin. Just configure your preferred Move to trash / Delete shortcuts inside Dolphin itself (Menu > Settings > Keyboard shortcuts). They override shortcuts configured in System Settings, so you can leave those at their defaults.