SUMMARY I wanted to assign a shortcut to trigger a restart of plasmashell. I wasted some time trying to understand why the command lines (which work correctly in a shell) were not working, until I realised the problem was the trigger sequence. STEPS TO REPRODUCE 1. Create a Command type shortcut, containing any of the following command lines- systemctl restart --user plasma-plasmashell kquitapp6 plasmashell; kstart plasmashell plasmashell --replace 2. Assign the trigger sequence of ctrl+r ("r" for restart), and apply 3. The shortcut is ignored ctrl+r does nothing. There are no errors either when defining the shortcut, or when typing the key sequence 4. Edit the trigger sequence to ctrl+p 5. The shortcut now works as expected?! OBSERVED RESULT Ctrl+R does not work as a shortcut trigger. The system will happily assign this as a trigger, but it does nothing. EXPECTED RESULT Ideally, the shortcut editor should only allow triggers to be defined that will work, If a trigger is not allowed for some reason, a meaningful error message should be shown. The next best option would be for whatever subsystem is rejecting or swallowing the ctrl+r sequence to provide a notification to the user along the lines of "key sequence disallowed because..." SOFTWARE/OS VERSIONS Operating System: Ubuntu 24.04.2 LTS (Noble Numbat) KDE Plasma Version: 6.3.1 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.11.0-17-generic (64-bit) Graphics Platform: Wayland ADDITIONAL INFORMATION
Presumably because it conflicts with the "Replace" common action (COmmon actions > Edit > Replace). I can't reproduce the issue though; when I try to assign the shortcut, I do indeed see a popup warning me of the conflict. Is it possible the popup appeared behind the main window, or on another monitor, or you missed it in some other way? Can you reproduce the issue in a new clean user account? Side note: for global shortcuts it's usually wise to include the Meta (AKA Windows or Super) key in some way, to minimize conflicts with in-app shortcuts.
I am beginning to realise that this problem was more subtle that I originally thought. I have found by experiment it's not just a matter of the comand you want to run and the chosen trigger, it's also down to whether (for example) you had one command assigned, and then go back and edit the command, or change the trigger. I have tried exporting the relevant sections of the shortcuts to a file, and found things like two different command strings in the file, but only one place where (think) the trigger sequence is defined. In the case I was looking at, one of the two command definitions appeared to be an "orphan" left behind when a definition was subsequently edited. I tied it on a fresh user account and as you say, attempting to assign "ctrl+r" brings up a warning, and the command "systemctl restart --user plasma-plasmashell" can be assigned to a shortcut, as long as you pick one that's not already assigned. So, questions- 1) It seems it's quite easy to break the key assignments config. For example I would not have knowingly ignored the warning about the "ctrl+r" trigger, but somehow I did try to assign that shortcut. Is there a simple way to reset the shortcut definitions to defaultsif they get corrupted? 2) Is the import+export format the System Settings tool uses for key assignments documented anywhere? 3) Is the import behavior of the shortcuts tool defined? I am mainly interested in whether an import file that defines just a few shortcuts will be merged into the current config, only overwriting any assignments to the same trigger sequences, or whether it will wipe out the current assignments and only create the new ones defined in the import file?
So you're speculating that this might have happened because at some point in the past, you used the import or export shortcuts feature, and they didn't result in a config file that was properly populated? I don't know the precise answers to your questions, but I do know import/export feature is not very commonly-used, so it wouldn't surprise me if it's a bit buggy.
I have found the shortcut editor to be a tad fragile. With more practice I've found you can make it work, at least for the few simple cases I have tried, by handling it with kid gloves. By which I mean- * Create one shortcut at a time * Don't edit a shortcut, delete it and create a new one * Save after every change, and- * To be really safe, quit the shortcut editor after every save, then restart it for the next item It's laborious, but for a small number of items it's do-able. If I had a complete custom configuration to set up like the real "keyboard warriors" do I think it would be rather exasperating.
As for the specific issue you originally reported, any chance you could figure out a set of steps to reproduce that make it happen 100% of the time for you?
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!