[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: "Gregor Mi" <codestruct () posteo ! org>
Date: 2015-04-29 13:47:55
Message-ID: 20150429134755.21733.21038 () mimi ! kde ! org
[Download RAW message or body]
--===============2795996298036147478==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
> 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?
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
-----------------------------------------------------------
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
>
>
--===============2795996298036147478==
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 p.m. 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 p.m. 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 p.m. 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 p.m. 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 a.m. 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 a.m. 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 a.m. 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>
<p>On April 27th, 2015, 8:59 a.m. UTC, <b>Thomas Lübking</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;">"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> </blockquote>
<p>On April 27th, 2015, 8:41 p.m. 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 input.</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;">The client MIGHT \
respond by dying, but there's NO HARD guarantee</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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?</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;">is part of managing \
your desktop?
-> Would such item belong into eg. the cashew then? Or a button in the config \
mode?</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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").</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p></pre> \
</blockquote>
<p>On April 27th, 2015, 9:03 p.m. 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;">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.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">One possible solution \
could be to show a hint in the conform dialog that is displayed when clicking the \
"End Process" button.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">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.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">Would that make \
sense?</p></pre> </blockquote>
<p>On April 27th, 2015, 9:56 p.m. UTC, <b>Thomas Lübking</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;">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.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Gregor, what situation caused the need for the xkill invocation? Unmanaged, \
undecorated or remote client? Sth. entirely different?</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;">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.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">at Thomas L.</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;">what situation caused the need for the xkill \
invocation?</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">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.</p></pre> <br />
<p>- Gregor</p>
<br />
<p>On April 20th, 2015, 10:24 p.m. 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 p.m.</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>
--===============2795996298036147478==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic