Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

Thu May 21 22:10:34 BST 2015

> On April 20, 2015, 10:36 p.m., Thomas Pfeiffer wrote:
> > What would likely be confusing is that the two button modes have different interaction flows: The "End Process" mode requires to first select a process and then press the button to work, whereas the "Kill specific window" mode requires to first press the button and then select the window to kill, and users have no easy way to understand how each one works and why they work differently.
> > 
> > The ellipsis in the label "End Process..." adds to that confusion. It indicates that further input is necessary before the action can take effect. While the button does open a dialog to confirm killing the selected process, ellipses are actually reserved for actions where a dialog asks for new information, such as the "Save As..." button, not for actions that require confirmation.
> > 
> > To avoid this confusion, it should be possible to also click "End Process..." even if no processes has been selected, whuch would then ask the user to select the process to kill. This could theoretically be done similarly to the "Kill specific window" function: Click the "End Process..." button and then click the process in the list that you want to end. Alternatively, if no process had been selected when "End Process..." is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work.
> 
> Gregor Mi wrote:
>     Thanks for the feedback! The ellipsis in "End Process..." is the original design. According to your explanation this was wrong in the first place. What about removing the ellipses in both menu items so we will end up with "End Process" and "Kill a specific window"?
> 
> Thomas Pfeiffer wrote:
>     "Kill specific window" does always need additional input until it really does something, doesn't it? As I understood it merely changes the cursor to the kill cursor and then the user has to select the window to kill, right?
> 
> Gregor Mi wrote:
>     Erm, right. To be exact, "Kill specific window..." only shows a message box. But in the end - after the user presses the keyboard shortcut - the user has to select a window. So this seems to be a special case. The intention behind all this is to increase the discoverability of the hidden xkill feature.
> 
> Gregor Mi wrote:
>     > To avoid this confusion, it should be possible to also click "End Process..." even if no processes has been selected, whuch would then ask the user to select the process to kill.
>     
>     If "End Process" is clicked with no processes selected, there will be a message box which says that the user has to select one more more processes first.
>     
>     > This could theoretically be done similarly to the "Kill specific window" function: Click the "End Process..." button and then click the process in the list that you want to end.
>     
>     I think "Kill specific windows" should be considered as the special case here. Changing or extending the "End Process" workflow would introduce more complexity to the code.
>     
>     > Alternatively, if no process had been selected when "End Process..." is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a p>rocess could and should still work.
>     
>     This would be a topic for another RR.
>     
>     Summary of final changes for this RR:
>     
>     - I would change the "End Process..." to "End Process" (remove ellipsis). Ok?
>     - I am not sure if the ellipsis of "Kill specific window..." should be removed or not.
> 
> Thomas Pfeiffer wrote:
>     To be honest: The more I think about this feature, the less sense it makes to me in general.
>     What is XKill's usecase anyway? If an application works normally, one can just quit it normally. If an application is frozen, KWin quite reliably detects that when trying to close the window and allows to kill the process.
>     Usually "End process" is used for applications that do not have a window (either because they don't have a GUI in the first place or because the window has disappeared but the process is still there), in which case xkill would not help anyway.
>     Yes, there may be some situations where it's useful, but they are really corner cases. Yes, very few people know it's there, but very few people miss the function, either. I heve never wished there was a way to hard kill a window without using the Close button in the windeco, and I have never met one who did.
>     
>     So we're complicating the GUI with a split button only to explain a feature to users which the vast majority of them don't need in the first place.
>     
>     If I have missed the "killer usecase for xkill" which makes it necessary to make it a lot more visible, please tell me about it.
> 
> Martin Gräßlin wrote:
>     > If I have missed the "killer usecase for xkill" which makes it necessary to make it a lot more visible, please tell me about it.
>     
>     well, assume you have multiple GTK CSD windows of an application open (e.g. GEdit). One of the windows hangs, you cannot close through KWin, because well CSD doesn't allow that. At the same time you don't know which process it is, because each of the windows is a gedit process. XKill will solve that problem.
> 
> Thomas Lübking wrote:
>     "Selber schuld; benutz' gefälligst anständige Software!" :-P
>     
>     1st off, an info that might be relevant for Thomas P. and Gregor:
>     XKill is a bit special, for even the KWin variant will in very doubt just cut the connection between the client and the X11 server. The client *MIGHT* respond by dying, but there's NO HARD guarantee that you actually killed a client this way (ie. in worst case you closed the window but the client keeps running in a life lock, ie. still uses 100% CPU)
>     
>     So here's out obstacle game =)
>     
>     The task is to either
>     1) "close" a window that has no decoration (Alt+F3 obstacle) or is simply unmanaged (requires a Promaster level 10 ;-)
>     2) "kill" a client, because you know/suspect it's no more responding but do not know that closing attempts would offer a kill (ie. you've knowledge in process management but cannot tie the window to the hanging PID)
>     
>     For (2) I added a special button to the bespin deco that would show a popup/dialog with some window properties, we could have such in the "more actions" submenu? ("Technical window informations ...")
>     
>     (1) is really a problem because the target audience likely won't know about ksysguard either?
>     Kicker had a bomb icon in its (SuSE?) defaults, what's oc completely over the top.
>     In addition there's the XKill vs. kill problem.
>     
>     Ignoring the latter (which is simply beyond the common user) for the moment, could one argue that "closing an unmanaged window" (xeyes! ;-) is part of managing your desktop?
>     -> Would such item belong into eg. the cashew then? Or a button in the config mode?
> 
> Gregor Mi wrote:
>     Thanks for the input.
>     
>     >  The client MIGHT respond by dying, but there's NO HARD guarantee
>     
>     I read that in the xkill manual. Currently, I wrote "See man xkill" in the message box for that :-). So, probably it would be better to include a more elaborate text?
>     
>     > is part of managing your desktop?
>     -> Would such item belong into eg. the cashew then? Or a button in the config mode?
>     
>     My original motivation for this RR was the following: I ran into a situation where I needed the xkill and I even remembered that there was some shortcut (because someone told me and I also tried it) but I couldn't come up with the correct one. So, I wondered what whould be a good place where I would search for the shortcut (without resorting to "the internet").
>     
>     I would very appreciate if at least KSysGuard would be an item of the cashew. The kill method might be a bit harsh to make it so public. My thoughts are: people who dare to kill a process using the "End Process" button are the same ones who would be happy to be educated with the existence and/or the shortcut of the xkill.
> 
> Thomas Pfeiffer wrote:
>     Okay, so it looks like that, though all quite niche, there are valid usecases for xkill. Still, a toolbar button that is labeled "Kill a specific window" but then only tells the user how to perform the action via a keyboard shortcut is not a good idea. It makes us look unprofessional.
>     
>     One possible solution could be to show a hint in the conform dialog that is displayed when clicking the "End Process" button.
>     
>     If users find themselves in the situation Martin described (Multiple instances of the same application of which one doesn't respond anymore and the user cannot tell which one in the process list it is), a user is likely to randomly try quitting one. In the following confirmation dialog, they'd be told
>     "If you are unsure whether this process belongs to a specific window that is frozen, you can try killing the window directly instead by pressing Ctrl-Alt-Esc and then clicking the frozen window. See also the manual entry on xkill" I would not even talk about the configurable shortcut in KWin because if a user has configured it to be something else, they know how to do it anyway, and if they have not, they likely won't care anyway.
>     
>     Would that make sense?
> 
> Thomas Lübking wrote:
>     For enabled compositing, ksysguard could also scan the window stack and highlight those (and itself) that can be assigned to the PID of the selected item.
>     
>     Gregor, what situation caused the need for the xkill invocation?
>     Unmanaged, undecorated or remote client? Sth. entirely different?
> 
> Gregor Mi wrote:
>     at Thomas P.:
>     I agree that the current solution is far from perfect. Currently, it seems to me as good compromise between implementation effort for a niche (but helping in case of emergency) feature, UI impairment and educating the user. Originally, I thought that it could be placed somewhere in the menu bar, but when you open "System activity" (Ctrl+Esc), there is no menu bar (the process table is a separate entity). Having a menu item makes sense to me because in some later step the message box could be extended with the real killing method. The xkill method needs mouse input to work so why not be able to invoke it using the mouse? In case you didn't read the whole thread: this kind of integration would require a great deal more implementation work (also in other compontents) to do it right, so it is postponed for now.
>     
>     at Thomas L.
>     > what situation caused the need for the xkill invocation?
>     
>     Unfortunenatly, I don't remember the exact context. It was some malfunctioning program that needs to be killed quickly. Probably it had no window decoration. Could also have been some fullscreen game.
> 
> Gregor Mi wrote:
>     Anything new on this one?

I still don't think this half-solution is worth implementing. It should either be implemented "properly" (i.e. with a button directly executing xkill) or not at all.

- Thomas

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/#review79262
-----------------------------------------------------------

On April 20, 2015, 10:24 p.m., Gregor Mi wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122249/
> -----------------------------------------------------------
> 
> (Updated April 20, 2015, 10:24 p.m.)
> 
> 
> Review request for KDE Base Apps, Martin Gräßlin, John Tapsell, and Thomas Pfeiffer.
> 
> 
> Repository: libksysguard
> 
> 
> Description
> -------
> 
> Current situation:
> The "End Process..." button has a tooltip which says "To target a specific window to kill, press Ctrl+Alt+Esc at any time." The keyboard shortcut is hardcoded.
> 
> New:
> Replace the "End Process..." button with a drop-down button and a action named "Kill a specific window..."
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt 66899e577a03786d894423a8f1ce5b3aeed6de8a 
>   processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 
>   processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 
>   processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c 
> 
> Diff: https://git.reviewboard.kde.org/r/122249/diff/
> 
> 
> Testing
> -------
> 
> 
> File Attachments
> ----------------
> 
> New End Process button with drop down arrow
>   https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/16301e88-e21b-4358-9a63-a85dae5722bd__screenshot_default1.png
> new submenu
>   https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/eeaecc88-20bc-46d6-9c65-50ba4a7c182a__submenu.png
> 
> 
> Thanks,
> 
> Gregor Mi
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150521/f957c455/attachment.htm>