> 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.
Anything new on this one?
- 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
>
>
