> 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? > > Thomas Pfeiffer wrote: > 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. > > Gregor Mi wrote: > I like the idea of giving the user some contextual hints instead of no > hint at all or a potentially wrong one as in the current tooltip. From this > point of view, the proposed implementation is an improvement. Currently (as > discussed above), the implementation of the invocation of the xkill is > technically not that easy, so this could be done in a second step. > > Gregor Mi wrote: > @Thomas P: Do you mean invoking the command line tool "xkill" (which > might not be installed) without showing an explaining message box? Would you > further keep the current tooltip over the "End Process..." button? (where > "press Ctrl+Alt+Esc anytime" could be wrong when the user configured the > shortcut otherwise). > > Gregor Mi wrote: > How to proceed with this? There are many different opinions and my code > proposal. > > In summary of the discussion above: I would like to see > 1) an increase on the discoverability of the Ctrl+Alt+Esc shortcut and > 2) display the correct shortcut also in case it was changed or being not > available at all. > > For me, keeping the situation as it is and do nothing, feels kind of > stale.
If someone has changed the shortcut, they should know what shortcut they set it to, right? So having the tooltip just say "To kill a specific window, press the "Kill Window" shortcut (Ctrl-Alt-Esc by default)" should do the trick, right? - 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 > >