| Summary: | UI for killing processes with different signals could be clearer | ||
|---|---|---|---|
| Product: | [Applications] plasma-systemmonitor | Reporter: | neobrain <bugs.7ng0x> |
| Component: | general | Assignee: | KSysGuard Developers <ksysguard-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | ahiemstra, nate, plasma-bugs |
| Priority: | NOR | Keywords: | usability |
| Version: | 6.1.3 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/plasma-systemmonitor/-/commit/8735b6603fc244b4efcc8b1f3dc2d2fb162f672b | Version Fixed In: | 6.2.0 |
| Sentry Crash Report: | |||
|
Description
neobrain
2024-07-28 16:21:57 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. > 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?
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. A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-systemmonitor/-/merge_requests/311 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 |