Bug 490934 - UI for killing processes with different signals could be clearer
Summary: UI for killing processes with different signals could be clearer
Status: RESOLVED FIXED
Alias: None
Product: plasma-systemmonitor
Classification: Applications
Component: general (show other bugs)
Version: 6.1.3
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: KSysGuard Developers
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2024-07-28 16:21 UTC by bugs.7ng0x
Modified: 2024-09-08 09:49 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.2.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bugs.7ng0x 2024-07-28 16:21:57 UTC
SUMMARY
Pressing the DEL key in the Processes view in System Monitor will end the selected process via SIGTERM. However, very often processes get stuck in ways that require use of SIGKILL for termination. In Plasma 5, you could do this by pressing SHIFT+DEL, or by holding SHIFT while selecting the "End process" context menu item. Since Plasma 6, SHIFT+DEL is still recognized but has the same behavior as DEL.

You can go through "Context menu -> Send Signal -> KILL" instead, but SIGKILL is needed often enough to warrant a more prominent exposure. It's also easy to forget which of the poorly named POSIX signals is the desired one (TERM? KILL? STOP?), whereas "Hold shift to force termination" is a straightforward mental model.

STEPS TO REPRODUCE
1. Open the Processes view in System Monitor
2. Select any process by clicking on it
3. Press SHIFT+DEL, or hold shift while triggering the "End Process" context menu action

OBSERVED RESULT
System Monitor offers to end the process via SIGTERM.

EXPECTED RESULT
System Monitor should offer to end the process via SIGKILL.

When holding shift in the context menu, the "End Process" action should change to something like "End process (force)".

SOFTWARE/OS VERSIONS
Linux: openSUSE Tumbleweed 6.1.3
KDE Plasma Version: 6.1.3
KDE Frameworks Version: 6.4.0
Qt Version: 6.7.2

ADDITIONAL INFORMATION
See also bug 439123 that originally requested the SHIFT+DEL shortcut.
Comment 1 Nate Graham 2024-08-12 20:37:48 UTC
While investigating fixing this, I found that in fact Shift+Delete already does exactly what you want it to do: sends a SIGKILL, while Delete without the shift key sends a SIGTERM. Just verified this with current git master.

"End process" is generic enough in text that changing it to something specific and technical only when holding Shift doesn't make sense IMO.
Comment 2 bugs.7ng0x 2024-08-13 09:22:53 UTC
> While investigating fixing this, I found that in fact Shift+Delete already does exactly what you want it to do: sends a SIGKILL, while Delete without the shift key sends a SIGTERM. Just verified this with current git master.
> 
> "End process" is generic enough in text that changing it to something specific and technical only when holding Shift doesn't make sense IMO.

Great to know the option is available after all at least. It didn't occur to me observe behavior that closely, but I couldn't disagree more with the conclusion here.

Is it really good UX to have two slightly different actions trigger the same (visually indistinguishable) dialog, which subsequently triggers a different action? This might be acceptable if the outcome would be visibly different (aiding in discoverability of the feature), but a SIGTERM can't be distinguished from a second SIGKILL working "after all".

It's also natural to assume that since "SHIFT+DEL" sends a SIGTERM, clicking "End Process" while holding SHIFT would do the same. This is not the case either, making the UI inconsistent and the feature even less discoverable.

Dolphin, for example, behaves like this: The menu action "Move to trash" is bound to the "DEL" key, but when holding SHIFT that menu action changes to "Delete" (bound to "SHIFT+DEL"). This makes the feature self-consistent and discoverable. Why wouldn't the same be done for the system monitor?
Comment 3 Nate Graham 2024-08-13 18:21:17 UTC
Yes, changing the dialog to mention what kind of signal it will send does seem reasonable. Perhaps we could also improve the UX for the context menu if we make the initial state more detailed so that changing it when holding down Shift makes sense.
Comment 4 Bug Janitor Service 2024-09-03 17:34:40 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-systemmonitor/-/merge_requests/311
Comment 5 Nate Graham 2024-09-08 09:49:15 UTC
Git commit 8735b6603fc244b4efcc8b1f3dc2d2fb162f672b by Nate Graham.
Committed on 08/09/2024 at 09:49.
Pushed by ngraham into branch 'master'.

Display signal type when SIGKILL'ing a process or application

System Monitor allows you to send two types of signals to kill processes
or apps: SIGTERM or SIGKILL. However the UI in the kill dialog doesn't
tell you which one is being used, making it difficult to verify that you
used the one you wanted.

This commit solves that problem by changing the terminology when using
SIGKILL: use the word force/forcibly to distinguish it from normal
quitting, and mention the signal name.

Since those strings were being touched, it also slightly re-words them
for better HIG conformance.
FIXED-IN: 6.2.0

M  +13   -4    src/faces/applicationstable/contents/ui/FullRepresentation.qml
M  +13   -4    src/faces/processtable/contents/ui/FullRepresentation.qml

https://invent.kde.org/plasma/plasma-systemmonitor/-/commit/8735b6603fc244b4efcc8b1f3dc2d2fb162f672b