[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyb
From: Thomas_Lübking <thomas.luebking () gmail ! com>
Date: 2015-04-27 8:59:34
Message-ID: 20150427085934.14758.97681 () mimi ! kde ! org
[Download RAW message or body]
--===============5092695781232737595==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
> On April 20, 2015, 10:36 nachm., 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.
"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?
- 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 nachm., 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 nachm.)
>
>
> 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
>
>
--===============5092695781232737595==
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="12" style="border: 1px #c9c399 \
solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;"> \
<tr> <td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/122249/">https://git.reviewboard.kde.org/r/122249/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On April 20th, 2015, 10:36 nachm. UTC, <b>Thomas \
Pfeiffer</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;"> <pre style="white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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.</p></pre> </blockquote>
<p>On April 20th, 2015, 10:44 nachm. UTC, <b>Gregor Mi</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">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"?</p></pre> </blockquote>
<p>On April 20th, 2015, 11:15 nachm. UTC, <b>Thomas Pfeiffer</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">"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?</p></pre> </blockquote>
<p>On April 22nd, 2015, 9:38 nachm. UTC, <b>Gregor Mi</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p></pre> </blockquote>
<p>On April 24th, 2015, 8:59 vorm. UTC, <b>Gregor Mi</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><blockquote \
style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid \
#bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;"> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">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.</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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.</p> <blockquote style="text-rendering: inherit;padding: 0 0 0 \
1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: \
inherit;"> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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.</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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.</p> <blockquote style="text-rendering: \
inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 \
0 0 0.5em;line-height: inherit;"> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">This would be a topic for another RR.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Summary of final changes for this RR:</p> <ul style="padding: \
0;text-rendering: inherit;margin: 0 0 0 1em;line-height: inherit;white-space: \
normal;"> <li style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: normal;">I would change the "End Process..." to "End Process" \
(remove ellipsis). Ok?</li> <li style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: normal;">I am not sure if the ellipsis of "Kill \
specific window..." should be removed or not.</li> </ul></pre>
</blockquote>
<p>On April 27th, 2015, 12:32 vorm. UTC, <b>Thomas Pfeiffer</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">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.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">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.</p></pre> </blockquote>
<p>On April 27th, 2015, 5:59 vorm. UTC, <b>Martin Gräßlin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><blockquote \
style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid \
#bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;"> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">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.</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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.</p></pre> </blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">"Selber schuld; benutz' gefälligst anständige Software!" :-P</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">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 <em style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
normal;">MIGHT</em> 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)</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">So \
here's out obstacle game =)</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">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)</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">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 ...")</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">(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.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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?</p></pre> <br />
<p>- Thomas</p>
<br />
<p>On April 20th, 2015, 10:24 nachm. UTC, Gregor Mi wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="12" style="border: \
1px #888a85 solid; border-radius: 6px; -moz-border-radius: 6px; \
-webkit-border-radius: 6px;"> <tr>
<td>
<div>Review request for KDE Base Apps, Martin Gräßlin, John Tapsell, and Thomas \
Pfeiffer.</div> <div>By Gregor Mi.</div>
<p style="color: grey;"><i>Updated April 20, 2015, 10:24 nachm.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
libksysguard
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" \
style="border: 1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">New: Replace the "End \
Process..." button with a drop-down button and a action named "Kill a specific \
window..."</p></pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>CMakeLists.txt <span style="color: \
grey">(66899e577a03786d894423a8f1ce5b3aeed6de8a)</span></li>
<li>processui/CMakeLists.txt <span style="color: \
grey">(7f87b85e0201e63d69070a71203bbb34851a79c6)</span></li>
<li>processui/ProcessWidgetUI.ui <span style="color: \
grey">(e50f55cf1813b00d49b1716023df487ffbd536e3)</span></li>
<li>processui/ksysguardprocesslist.cpp <span style="color: \
grey">(450ca600b8aed7ca611ec638610b6c524c96080c)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/122249/diff/" style="margin-left: \
3em;">View Diff</a></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">File Attachments \
</h1>
<li><a href="https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/16301e88-e21b-4358-9a63-a85dae5722bd__screenshot_default1.png">New \
End Process button with drop down arrow</a></li>
<li><a href="https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/eeaecc88-20bc-46d6-9c65-50ba4a7c182a__submenu.png">new \
submenu</a></li>
</ul>
</td>
</tr>
</table>
</div>
</body>
</html>
--===============5092695781232737595==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic