System Monitor has no Kill button

[Rich Jones]

When an application is misbehaving, the user will open System Monitor to end it. Unfortunately, most of the time, End Process is not enough, and the application needs to be killed. However, there is no button do to so. Right clicking on the misbehaving process in question reveals a Kill option, but this isn't intuitive.

There should be a second button added so that the user has options to 'End Normally' and 'Kill Forcibly,' which should be quite satisfying.

Really easy fix, just add one more GTK button which has already been coded for.

[Lorenzo (lorenzo-delledonne)]

Thanks for this bug report!
I can confirm it as a paper cut.

[Lorenzo (lorenzo-delledonne)]

Also, it would be useful (maybe in another paper cut?) to have, right after the tab opening, the focus on the treeview and a shortcut key for both "End Process" and "Kill Process".
I must say that actually the distinction between "ending" and "killing" a process might not be so bright for most users. Ideas?

Right now, I consider "htop" much more effective: Process selection by arrow keys --> F9 --> 9 (for the SIGKILL message). Bum.

[Rich Jones (richwjones)]

I think the way to distinguish between ending and killing it to describe a bit about what they actually do, like I said 'End Normally' and 'Kill Forcibly.' Or, perhaps, 'End Process Normally' and 'Kill Process Forcibly,' although this is more verbose.

[Rich Jones (richwjones)]

Okay, I have fixed this problem, here is an image

[Rich Jones (richwjones)]

And here is the patch!

Apply to /src

[Rich Jones (richwjones)]

Should I email the guy upstream?

[Rich Jones (richwjones)]

How come this isn't on the Karmic blueprint? I already wrote the patch.. what happens next? Can somebody apply it? Should I talk to somebody else?

[Vish (vish)]

@Rich Jones:
To get it into papercuts you need to discuss with David Siegel, He'll add it to a Karmic milestone.

That aside, the patch needs a bit of alteration....
Space between the 2 buttons is too close for comfort. , its just around 2px , atleast 10px is needed .
End process label , could be just "End Process" , normally is implied when the other button has Forcibly.

[Martin Albisetti (beuno)]

I agree this is something to fix, but I'm not yet sure what the right way to do it is.
How do we make sure the user understands the difference between one option and the other?
Should we maybe *just* provide kill? or only offer you after you've tried to terminate the process once?

[Rich Jones (richwjones)]

Why?

Users aren't stupid and will make the correct decision, IF things are properly laid out for them. In this solution, the buttons are very clearly labeled, providing two intuitive options. End Process Normally, meaning end this process as if I had pressed the 'X' button on the window, and Kill Process Forcibly, for when I've tried hitting the X button but it won't go away. Both options are necessary and intuitive because they are labeled properly. Having one as End Process and the other as Kill Process Forcibly is asymmetric and less explanatory. Implication is to be avoided in user interface design, being explicit is a good thing.

As for having only a kill button, this provides less power to the user and reintroduces the 'lonely button' problem.

[Martin Albisetti (beuno)]

It's not about people being stupid or not, it's about people not knowing the difference between ending process normally and killing it.
Why would they be there in the first place?
I'm not arguing one way or the other, I'm saying that this needs to be treated with care to not introduce "feature creep". We need to mock it up, test it a bit, etc. It's a papercut in the sense that it's technically easy to fix, but the UI is not straightforward.

[Rich Jones (richwjones)]

Attached is a the same patch but with proper 10 pixel spacing.

I don't think this is 'feature creep' as the feature was already there and coded for, just only available as a right-click option. Now there is a properly labeled button for it, which also means that the other button isn't lonely and awkward.

Apply to /src/

[Rich Jones (richwjones)]

Image attached

Ignore the hilarious big pointer.

[Rich Jones (richwjones)]

Fixed the formatting and spacing up a bit. Sorry about this spamming.

[Rich Jones (richwjones)]

And the proof..

[Rich Jones (richwjones)]

Derpa derp..

[David Siegel (djsiegel-deactivatedaccount)]

There is great work being done here, but this is not a paper cut; most users do not think of "killing" processes; when a process freezes, they may use the "force quit" dialog, but opening System Monitor, looking up an errant process in the process table there, and pressing a "kill" button to terminate it is certainly not a workflow exhibited by average users.

[David Siegel (djsiegel-deactivatedaccount)]

Also, I know you chose the work "kill" for historical reasons, but instead of "Kill Process Forcibly" I recommend something a little less violent (and a little less mouthy) for the two buttons:

Instead of:

  "End Process Normally" "Kill Process Forcibly"

try:

  "Quit Process" "Force Quit Process"

[Rich Jones (richwjones)]

The problem with that is that it isn't Linux. 'Kill' is significant, as we are sending the KILL signal.

[David Siegel (djsiegel-deactivatedaccount)]

Rich, isn't that UNIX, not Linux? ;)

I am just suggesting that "Force Quit Process" will be more usable than "Kill Process" to our users. Should we change "Shut Down" to "Halt"? Why not "SIGKILL" instead of "Kill"? If you don't want to put the user first, and would rather adhere to your idea of what Linux means and how that should manifest itself in a GUI, instead of making the software friendlier, less offensive, and easier to figure out, we won't make any progress.