SUMMARY Please make confirming a process kill take fewer keypresses. STEPS TO REPRODUCE Here is my typical usage scenario: - open systemmonitor: meta + esc, which I would count as one keypress - filter processlist (after having set it the default view): a few keypresses, which I think is not a problem - request kill: one key press (del or shift+del) - confirm kill: tab (focusses "do not ask"), tab (focusses "terminate"), space (submits), so three keypresses Also, for some reason pressing the enter key on the confirm kill dialog does no submit the dialog, even when the confirm button already has the focus. This feels unexpected to me. OBSERVED RESULT Just confirming a process kill takes more keypresses than both opening systemmonitor and requesting the kill taken together. This seems suboptimal. EXPECTED RESULT I think pressing (shift-)delete then enter (2 key presses) should go from the process list to the selected process getting (force-)killed. I also think pressing enter after the confirm button is selected should trigger that button's action. Once the latter point is resolved, I think having the confirm button getting default focus in that dialog would resolve this issue. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian GNU/Linux 13 KDE Plasma Version: 6.3.5 KDE Frameworks Version: 6.13.0 Qt Version: 6.8.2
In general, we don't recommend that the default button in a dialog be destructive. The way QtWidgets dialogs get around this is by allowing arrow key navigation between buttons, to selecting the destructive one is easy. There's one exception: the file "Delete permanently" dialog which IMO should be changed. But we tried that a while back and people whose muscle memory was accustomed to the way things were put up a big fight about it. Another thing I think would make a difference here would be to use the Down arrow key to go from the default-focused search field to the processes list.
> - filter processlist (after having set it the default view): a few keypresses, which I think is not a problem > - request kill: one key press (del or shift+del) Side question: In between of these steps, how do you change focus to select a process in the table? I tried these keys, but none of them focus the table: * Enter * Arrow keys (Up / Down) * Tab (pressed it 20+ times). So far, it seems to me like killing a process isn't possible at all, unless you additionally use the mouse.
For me, five presses of the Tab keys moves focus into the Processes view. I'm on Wayland with git master versions of all KDE software though.
> For me, five presses of the Tab keys moves focus into the Processes view. I'm on Wayland with git master versions of all KDE software though. Re-tested on 6.4, was able to focus the view in 6 presses of the Tab key. Operating System: Fedora Linux 41 KDE Plasma Version: 6.4.1 KDE Frameworks Version: 6.15.0 Qt Version: 6.8.3 Kernel Version: 6.15.4-100.fc41.x86_64 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz Memory: 16 ГиБ of RAM (15.4 ГиБ usable) Graphics Processor 1: Intel® HD Graphics 530 Graphics Processor 2: NVIDIA GeForce GTX 960M
Navigating the list is however not the best experience. Filed https://bugs.kde.org/show_bug.cgi?id=508983.
(sorry, I missed the reply notifications) (In reply to Alexander Potashev from comment #2) > Side question: In between of these steps, how do you change focus to select > a process in the table? Good question. I must have used the mouse for this step without thinking about it. I have the impression that pressing the down arrow would be intuitive. I was somewhat used to how it worked in the older systemmonitor UI, one with a single process list but now that I have updated all my machines I do not remember for sure how that worked.
(In reply to Nate Graham from comment #1) > In general, we don't recommend that the default button in a dialog be > destructive. I would argue that in the case of this dialog I went through several actions already to get to this dialog. Of course maybe I selected the wrong process and am going to trigger the default action. > The way QtWidgets dialogs get around this is by allowing arrow key > navigation between buttons, to selecting the destructive one is easy. Trying this now this does not seem to work: if I press the tab key until either button is highlighted, then press the arrow towards the other button, the highlight does not move. If I do press the left key then the right key (or vice versa) then the highlight disappears from the initially highlighted button without appearing anywhere (not on the other button, not on the "do not ask" checkbox). I cannot tell if this is a visual bug or if focus is actually being removed rather than moved. FWIW I am currently on systemmonitor 6.3.6, KDE 6.13.0, Qt 6.8.2 and on Wayland.