> 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?
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. - Gregor ----------------------------------------------------------- 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 > >