[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 Pfeiffer <colomar () autistici ! org>
Date: 2016-01-25 20:36:48
Message-ID: 20160125203648.17778.27567 () mimi ! kde ! org
[Download RAW message or body]
--===============2272826512405639280==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
> On Jan. 23, 2016, 5:31 p.m., Gregor Mi wrote:
> > > 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?
> >
> > In principle, I agree with you here. :) But...
> >
> > I have these premises in mind:
> >
> > 1. There might be a situation where the user can't remember what he has done.
> > 2. I prefer precise over approximate information if it is reasonable easy to get (by fixing this \
> > https://git.reviewboard.kde.org/r/122981/ it is now easily possible and the patch is already written) \
> > 3. Somewhere I read that tooltips are to be avoided where possible => this patch factors some \
> > information out of a tooltip which in itself is desirable. 4. For the user, the discoverability of \
> > the feature after applying this patch is better than before (though not perfect, sure).
>
> Thomas Pfeiffer wrote:
> 2. If we can get the current shortcut, why can't we get it for the tooltip?
> 3. Wait, are we talking about different tooltips? I do _not_ mean the one you get when clicking the ? \
> icon in the window decoration. Those should be avoided because few people even notice that button. What \
> I mean is the thing that pops up when hovering over a control. Those are strongly encouraged in the \
> HIG, in fact they should be used on every control where the function isn't clear from the label. 4. \
> Clicking a button just to get explained how to use a shortcut is just not good. When users click a \
> button (unless it's a help button), they expect something to happen. And still: We're putting something \
> in the UI which is used only a single time (afterwards the user knows that the function exists)
> Gregor Mi wrote:
> 2. "Put it into the tooltip": Yes, sure this can and should be done. But also see point 5.
>
>
> 3. "Tooltips": oh, I indeed meant the Tooltips which you say are strongly encouraged in the HIG. My \
> mistake, thanks for clearing that!
>
> 4a. "Clicking a button": the original idea was that clicking the button actually triggers the function \
> but for current technical reasons it was postponed. So, adding the menu item now might motivate someone \
> to go a step further and implement the rest. One step at a time.
> 4b. "only used a single time": I myself am a user and due to the outstanding stability of the desktop I \
> keep forgetting these shortcuts. ;-) Seriously, often I found myself in a situation where I knew there \
> is a shortcut but could not remember which (and previously I was lost completely because I did not know \
> that the killing window function exists at all). By now I think I will never forget it, though. :)
> 5. Funnily, the first time I actually saw that the shortcut is documented in the toolip was when I \
> began to change the code to prepare this RR to make the shortcut more visible. :) Sure, this only a \
> single user report but I don't think I am the only who does not read the whole tooltip.
> Ken Vermette wrote:
> As I see it here, the current solution isn't good and I'd argue against changing things just because \
> they feel stale. Mainly you're trading one less-than-ideal solution (using a tooltip) in exhange for a \
> solution which is more complicated and bloats the UI. Why do we need to go so far out of our way to \
> advertise XKill when we are capable of killing apps from the monitor? Users of the monitor familliar \
> with the system chould not have purely informational menus burned into the main UI.
> Split buttons are also abused regularly, and it's not clear what the "V" menu offers until activated. \
> Why would someone who won't stop for a tooltip know to press the "V" button? What if they assume it's \
> for other actions like pause, suspend, and resuming the selected process? Users *still* won't click it \
> if that's the case. This is essentially a much more convoluted tooltip which works under the assumption \
> users will investigate it because it's disguised as functionality.
> I also dislike that it advertised as a feature and not a help option, and users with a crashing/frozen \
> application will only be more frusterated if they think they have a solution - and are instead given a \
> manual. Nowhere else do we use this pattern. Information should NEVER be disquised as functionality; it \
> **severly** degrades user trust. Imagine if every application did this - would you use a system which \
> kept popping up with info boxes instead of doing the work? Especially when you *need* the system to \
> take care of a problem and the system tells you "I can't do this, try doing this" - I can think of no \
> better way to shatter a users trust; one thing is already broken, we should not make it feel *more* \
> broken.
> Finally, xkill is a separate utility entirely, I question if it should be advertised at all in \
> ksysguard. One is a UI-oriented solution, one is a shortcut solution. Should Kate advertise KDevelop \
> features? Should Juk advertise Amarok? Should the volume control widget advertise the Pulse command \
> line utilities? Just because they do related things doesn't necessarily mean they should advertise \
> each-other.
> Anyway, I would propose one of these alternative solutions:
> - Having a tip at the bottom of the window between the task list and status bar which goes: "(i) You \
> can force close a specific window by pressing #shortcut#". This tip could be closed/hidden permanently \
> by the user.
> - Moving the information to the "help" menu. Help > "How to kill a window". A little less discoverable, \
> but much more appropriate.
> - Have it actually perform the function. The option will launch an [OK|Cancel] dialog with "You will \
> force-close the next window you click on. Hit ESC to cancel at any time". When the user presses [OK] it \
> properly executes the xkill utility. This is more future-proof in case Kwin offers a nicer \
> KDE/Plasma-centric with the warnings and labels built-in, because we could just adapt this in the \
> future to use that.
> - Clean out the tooltip. Remove the parts on right-clicking and what-if. Users will visit help if they \
> need it, and right-clicking is common functionality. Instead of adding mroe to make thing visible, we \
> remove noise.
> - Leave it as-is. *This is an option.* There are lots of places we could be tempted to tell users about \
> our functionality, but the fact is there will always be things a computer can do that users don't know \
> about.
> As far as code complexity and keeping it less complex, I personally beleive that if we're introducing \
> code for *anything* it should at least be functional. To me increasing code complexity for a feature is \
> acceptible, but incrementing the complexity even a little for half-measures isn't really justifiable.
> Thomas Lübking wrote:
> On the bottom line, this is the "KWin has no real GUI" problem.
>
> Aside the xkill (we're more talking about the feature built into KWin than the x util here) there're \
> several other kwin features only available through shortcuts (eg. invert screen colors, a bunch of \
> effects, random scripts) and not even all window related actions (packing...) are somehow announced in \
> some GUI (too much pro stuff)
> Maybe the question is whether KWin needs an entry in eg. the systray where it can show a window which \
> exposes those features - including their assigned shortcuts or - as alternative - a "global" section in \
> the Alt+F3 menu?
> Gregor Mi wrote:
> Hi Ken,
>
> I go through your feedback paragraph by paragraph. I try to keep it short so it might seem a bit \
> abrupt.
> > Why do we need to go so far out of our way to advertise XKill when we are capable of killing apps \
> > from the monitor?
>
> Because it would help users to find the feature. For me, it is one of those features that I don't look \
> for if I don't know it exists. The system monitor which is able to kill processes is the most suitable \
> place to advertise this feature.
> > Why would someone who won't stop for a tooltip know to press the "V" button?
>
> The tooltip should be used "where the function isn't clear from the label" (said Thomas Pfeiffer \
> above). This implies that when the user thinks that the meaning of the button is clear he probably \
> won't read the tooltip.
> > I also dislike that it advertised as a feature and not a help option, and users with a \
> > crashing/frozen application will only be more frusterated if they think they have a solution - and \
> > are instead given a manual
>
> I disagree: if I as a user am in a situation where I need help, I am glad I get some, and be it a \
> pointer to some manual. It is better than nothing. For example gparted does this when you are about to \
> move your systems hard drive: it shows a message box with a short explanation and a link to a howto of \
> how to make your system bootable in case of problems. Good thing for me.
> Plus: if the system or application gives some hint of how one can do things (better), one should be \
> grateful and not grumpy.
> > Imagine if every application did this - would you use a system which kept popping up with info boxes \
> > instead of doing the work?
>
> Surely not. I don't like that either. And I don't think if this RR was accepted as is (see also below), \
> a landslide will break loose and everyone would adapt this pop-up pattern. ;-)
> > Anyway, I would propose one of these alternative solutions:
>
> Thanks for these suggestions. I'll comment on them:
>
> > - Having a tip at the bottom of the window between the task list and status bar which goes: "(i) You \
> > can force close a specific window by pressing #shortcut#". This tip could be closed/hidden \
> > permanently by the user.
>
> This would advertise the feature very prominent. It could be extended with a button to trigger the \
> feature. Downside: the "hide permanently" option must be properly implemented. What if I want the \
> message back?
> > - Moving the information to the "help" menu. Help > "How to kill a window". A little less \
> > discoverable, but much more appropriate.
>
> This was discussed but then it would not show up in the Ctrl+Esc "System Activity" window because there \
> is no Help menu.
> > - Have it actually perform the function. The option will launch an [OK|Cancel] dialog ...
>
> I had this actually implemented. It did work fine. This is what I liked best but sadly there were \
> technical concerns of calling the DBus interface of KWin (see explanations of Martin and suggestions of \
> Thomas L in the first thread).
>
> I agree with you that the split button is not the best solution. I also don't like it so much. Here is \
> another option:
> Add a new button right next to the "End Process..." button, so it would look like this:
>
> "[End Process...] [More...] [Quick search]"
>
> The More... button (instead of text it could be also an icon that looks like "more") would open a menu \
> with currently one item:
> - "Kill a window by clicking on it"
> which would either call the feature directly (if technically possible) or show a message box with the \
> shortcut until it is technically possible.
> What do you think?
>
> Gregor Mi wrote:
> > Maybe the question is whether KWin needs an entry in eg. the systray where it can show a window which \
> > exposes those features
>
> A systray entry would be a GREAT thing! :-) Apart from the features you mentioned one could have an \
> easy entry point for features like the magifier etc. Those features are really great. And there would \
> be a visible entry point for the "Desktop Effects" dialog and maybe even the "Display settings". +1 \
> from me!
> Thomas Pfeiffer wrote:
> I'm sorry Gregor, but you still have not provided a convincing argument for your patch. A "More" menu \
> with only one entry that in turn opens a dialog to explain what pressing a shortcut does? This may not \
> make users grumpy, but this is exactly the kind of bloated UIs that people associate - negatively - \
> with KDE software. Xkill is really only useful in very edge cases. For full-screen applications it's \
> easy to find their name in the list since one usually doesn't have more than one application running \
> fullscreen at the same time. If removing the decoration is the problem, then I'd rather show a \
> KMessageWidget in places where the user can configure this to explain "If a borderless window becomes \
> unresponsive, press <shortcut> and click it to kill it". Also: Shouldn't pressing Alt-F4 on an \
> unresponsive borderless window still evoke KWin's kill feature?
> Cluttering the main UI with rarely-used features is bad enough. Cluttering it with explanations for \
> rarely-used features is worse.
> If this was a very importantbut still hard to discover feature, I'd begrudgingly accept the solution to \
> advertise it in a dialog, but for an edge-case function? No, sorry. Unless you can make a case where \
> xkill is the only way to prevent data loss, I cannot accept this.
> Ken Vermette wrote:
> While it would be great if the feature was advertised and I understand the logic, the system monitor \
> doesn't exist soley for killing applications - that's just a major use-case. If we extend the UI for \
> features which the monitor doesn't even have, it's bloating it for an anti-pattern. While I don't \
> expect a landslide of applications will use the anti-pattern my point is that we shouldn't add them \
> knowing it's not acceptable practise, and it holds us to a lower standard when we say "good enough".
> The main concern I have is the fact that it breaks the users trust in the abilities of a program when \
> it outright states you can't do something through the UI. This is my biggest problem, and one I'd need \
> addressed before giving a thumbs up. If I tried to use Kate and the find/replace button opened a popup \
> saying "hit ctrl+r", I would drop that application faster than a bad habit, I might even perceive it as \
> trying to dictate my workflow. If I were a new user to ksysguard and I encountered that dialog, I \
> wouldn't use it. I wouldn't trust it to be able to fufill functionality it claims to offer, I'd \
> question every UI element assuming it would let me down.
> Additionally if a user pressed this button or opened the menu, they have learned. Now the button is \
> useless to that user forever. So we have a UI element burned into the interface which the user knows is \
> not only useless, but will spawn a popup that slows them down. In the case the user forgets the \
> shortcut it doesn't guarantee they'll remember which application told them the information, or where in \
> that application it told them.
> It's having a "tip of the day" button permanently embedded in a program, but it only ever displays one \
> tip. I'm sorry, xkill is great functionality, but the monitor is not the appropriate place for \
> advertising it. As I've thought about it, it makes less sense to include any mention of it, I think \
> we'd be better off with a desktop-level overlay or application that displays shortcuts where users can \
> consistently reference important informaiton. Maybe if it's an app, add it to the favourites in \
> launchers by default. Again, I'm sorry, but I just don't think this is the appropriate place to embed \
> random information.
> Gregor Mi wrote:
> > A "More" menu with only one entry that in turn opens a dialog to explain what pressing a shortcut \
> > does?
>
> Ok, I added two new screenshots. One that shows the System Activity window which is triggered by \
> Ctrl+Esc as is and the other one with an added "Tools..." button.
> When the button is clicked a menu could open with these items (more than one and each of them useful \
> for diagnosing the system):
> * System Monitor --> opens KSysuard
> * KInfoCenter --> opens KInfoCenter which also has information about Memory and Energy usage
> * Run a command... --> lets the user enter a shell command
> * Kill a window by clicking on it (Ctrl+Alt+Esc) --> triggers the "xkill" feature (which is really a \
> KWin feature and not the actuall shell command) or shows a message box if KWin is not available.
> What do you think?
>
> Thomas Lübking wrote:
> General question to the HIG team:
> would you prefer the feature to be exposed in ksysguard or would you prefer a KWin \
> SysTray/Statusnotifier item? (Or neither ;-)
> Thomas Pfeiffer wrote:
> > When the button is clicked a menu could open with these items (more than one and each of them useful \
> > for diagnosing the system)
>
> This does indeed sound much more useful than a menu with only one entry, especially if the "Kill a \
> window by clicking on it" optiopn would actually do that. Though we should first decide on Thomas \
> Lübking's proposal.
> > would you prefer the feature to be exposed in ksysguard or would you prefer a KWin \
> > SysTray/Statusnotifier item? (Or neither ;-)
>
> Giving access to KWin's useful features which are currently hiden behind a shortcut via a GUI sounds \
> sensible to me. I'm not so sure if it should be in the Systray, however, since it's already overcrowded \
> with things. Then again, we could just put it into a Plasmoid which users could put wherever they want \
> - or nowhere at all if they don't care about the features. This should not just be informing about the \
> shortcuts, but allow to actually execute the functions directly by clicking on them.
> Martin Gräßlin wrote:
> Agreeing with Thomas L. on the general problem of KWin not having a GUI and that shortcuts are \
> difficult to find. But that's a problem not unique to KWin, but in general to global shortcuts. Could \
> the VDG gather some ideas how to make the shortcuts (including stuff like global touch gestures, etc) \
> better available to users?
> Gregor Mi wrote:
> I suggest to move the discussion and design work on the topic "KWin and general global shortcuts \
> handling" to a dedicated location. If this location is known - probably opened by someone from the VDG? \
> - please post back the link to it here for reference.
> Meanwhile, can I get consent from VDG for this RR to proceed with the "Tools..." menu button as \
> described in the recent discussion? (--> Ship it from VDG)
> After that, I would continue refine the implementation of this RR and expect only technical issues to \
> be discussed.
> (If the results of "KWin and general global shortcuts handling" become clear at some later point in \
> time, the commited implemenation of this RR can be revised.)
> Please feedback for this procedure.
>
> Gregor Mi wrote:
> I would like to add that I would like to thank you for your input to the discussion. For me, the \
> current state of this RR looks much more complete and sensible than in the beginning.
This approach makes sense. The discussion about a general "make the shortcuts more discoverable" solution \
has not started yet. I'll post a link when that happens. Since the entries int he Tools menu are merely \
handy shortcuts to other applications, if one of them isn't installed it simply should not show up in the \
menu. So make sure the menu contains only applications which are installed on the system. So this is a \
go-ahead from the VDG for the Tools menu solution.
- Thomas
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/#review91486
-----------------------------------------------------------
On Jan. 25, 2016, 6:51 p.m., Gregor Mi wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122249/
> -----------------------------------------------------------
>
> (Updated Jan. 25, 2016, 6:51 p.m.)
>
>
> Review request for KDE Base Apps, David Edmundson, 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
> ----------------
>
> DEFERRED: 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
>
> DEFERRED: new submenu
> https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/eeaecc88-20bc-46d6-9c65-50ba4a7c182a__submenu.png
> Ctrl+Esc, currently
> https://git.reviewboard.kde.org/media/uploaded/files/2016/01/24/8d537357-1e08-4d67-8b45-28933c1a0ccf__screenshot_20160124_115024.png
> Ctrl+Esc, with Tools... (menu contents see discussion)
> https://git.reviewboard.kde.org/media/uploaded/files/2016/01/24/71ebdcea-a793-460a-adb5-f05a7706f8b0__screenshot_20160124_115024-with-tools.png
>
>
> Thanks,
>
> Gregor Mi
>
>
--===============2272826512405639280==
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 January 23rd, 2016, 5:31 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;"><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 \
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?</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">In \
principle, I agree with you here. :) But...</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">I have these premises in mind:</p> <ol style="padding: \
0;text-rendering: inherit;margin: 0 0 0 2em;line-height: inherit;white-space: normal;"> <li \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">There \
might be a situation where the user can't remember what he has done.</li> <li style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">I prefer precise over \
approximate information if it is reasonable easy to get (by fixing this \
https://git.reviewboard.kde.org/r/122981/ it is now easily possible and the patch is already \
written)</li> <li style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
normal;">Somewhere I read that tooltips are to be avoided where possible => this patch factors some \
information out of a tooltip which in itself is desirable.</li> <li style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: normal;">For the user, the discoverability of the \
feature after applying this patch is better than before (though not perfect, sure).</li> </ol></pre>
</blockquote>
<p>On January 23rd, 2016, 6:16 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;"><ol style="padding: 0;text-rendering: inherit;margin: 0 0 0 \
2em;line-height: inherit;white-space: normal;"> <li style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: normal;">If we can get the current shortcut, why can't we get it for \
the tooltip?</li> <li style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: normal;">Wait, are we talking about different tooltips? I do <em style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">not</em> mean the one you \
get when clicking the ? icon in the window decoration. Those should be avoided because few people even \
notice that button. What I mean is the thing that pops up when hovering over a control. Those are \
strongly encouraged in the HIG, in fact they should be used on every control where the function isn't \
clear from the label.</li> <li style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: normal;">Clicking a button just to get explained how to use a shortcut is just not \
good. When users click a button (unless it's a help button), they expect something to happen. And still: \
We're putting something in the UI which is used only a single time (afterwards the user knows that the \
function exists)</li> </ol></pre>
</blockquote>
<p>On January 23rd, 2016, 7:42 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;"><ol style="padding: 0;text-rendering: inherit;margin: 0 0 0 \
2em;line-height: inherit;white-space: normal;"> <li style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: normal;"> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">"Put it into the tooltip": Yes, sure this can and should be \
done. But also see point 5.</p> </li>
<li style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">"Tooltips": oh, I indeed meant the Tooltips which you say are strongly encouraged in the HIG. \
My mistake, thanks for clearing that!</p> </li>
</ol>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">4a. \
"Clicking a button": the original idea was that clicking the button actually triggers the function but \
for current technical reasons it was postponed. So, adding the menu item now might motivate someone to go \
a step further and implement the rest. One step at a time.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">4b. "only used a single time": I myself am \
a user and due to the outstanding stability of the desktop I keep forgetting these shortcuts. ;-) \
Seriously, often I found myself in a situation where I knew there is a shortcut but could not remember \
which (and previously I was lost completely because I did not know that the killing window function \
exists at all). By now I think I will never forget it, though. :)</p> <ol style="padding: \
0;text-rendering: inherit;margin: 0 0 0 2em;line-height: inherit;white-space: normal;"> <li \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">Funnily, \
the first time I actually saw that the shortcut is documented in the toolip was when I began to change \
the code to prepare this RR to make the shortcut more visible. :) Sure, this only a single user report \
but I don't think I am the only who does not read the whole tooltip.</li> </ol></pre>
</blockquote>
<p>On January 23rd, 2016, 10:43 p.m. UTC, <b>Ken Vermette</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;">As I see it here, the current solution isn't good and I'd argue against \
changing things just because they feel stale. Mainly you're trading one less-than-ideal solution (using a \
tooltip) in exhange for a solution which is more complicated and bloats the UI. Why do we need to go so \
far out of our way to advertise XKill when we are capable of killing apps from the monitor? Users of the \
monitor familliar with the system chould not have purely informational menus burned into the main UI.</p> \
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Split \
buttons are also abused regularly, and it's not clear what the "V" menu offers until activated. Why would \
someone who won't stop for a tooltip know to press the "V" button? What if they assume it's for other \
actions like pause, suspend, and resuming the selected process? Users <em style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">still</em> won't click it \
if that's the case. This is essentially a much more convoluted tooltip which works under the assumption \
users will investigate it because it's disguised as functionality.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I also dislike that it \
advertised as a feature and not a help option, and users with a crashing/frozen application will only be \
more frusterated if they think they have a solution - and are instead given a manual. Nowhere else do we \
use this pattern. Information should NEVER be disquised as functionality; it <strong style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">severly</strong> degrades \
user trust. Imagine if every application did this - would you use a system which kept popping up with \
info boxes instead of doing the work? Especially when you <em style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: normal;">need</em> the system to take care of a \
problem and the system tells you "I can't do this, try doing this" - I can think of no better way to \
shatter a users trust; one thing is already broken, we should not make it feel <em style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">more</em> broken.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Finally, \
xkill is a separate utility entirely, I question if it should be advertised at all in ksysguard. One is a \
UI-oriented solution, one is a shortcut solution. Should Kate advertise KDevelop features? Should Juk \
advertise Amarok? Should the volume control widget advertise the Pulse command line utilities? Just \
because they do related things doesn't necessarily mean they should advertise each-other.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Anyway, I \
would propose one of these alternative solutions:
- Having a tip at the bottom of the window between the task list and status bar which goes: "(i) You can \
force close a specific window by pressing #shortcut#". This tip could be closed/hidden permanently by the \
user.
- Moving the information to the "help" menu. Help > "How to kill a window". A little less \
discoverable, but much more appropriate.
- Have it actually perform the function. The option will launch an [OK|Cancel] dialog with "You will \
force-close the next window you click on. Hit ESC to cancel at any time". When the user presses [OK] it \
properly executes the xkill utility. This is more future-proof in case Kwin offers a nicer \
KDE/Plasma-centric with the warnings and labels built-in, because we could just adapt this in the future \
to use that.
- Clean out the tooltip. Remove the parts on right-clicking and what-if. Users will visit help if they \
need it, and right-clicking is common functionality. Instead of adding mroe to make thing visible, we \
remove noise.
- Leave it as-is. <em style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: normal;">This is an option.</em> There are lots of places we could be tempted to \
tell users about our functionality, but the fact is there will always be things a computer can do that \
users don't know about.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">As far as code complexity and keeping it less complex, I personally \
beleive that if we're introducing code for <em style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: normal;">anything</em> it should at least be functional. To me \
increasing code complexity for a feature is acceptible, but incrementing the complexity even a little for \
half-measures isn't really justifiable.</p></pre> </blockquote>
<p>On January 23rd, 2016, 11:31 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;">On the bottom line, this is the "KWin has no real GUI" problem.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Aside the \
xkill (we're more talking about the feature built into KWin than the x util here) there're several other \
kwin features only available through shortcuts (eg. invert screen colors, a bunch of effects, random \
scripts) and not even all window related actions (packing...) are somehow announced in some GUI (too much \
pro stuff)</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Maybe the question is whether KWin needs an entry in eg. the systray where it can show a window \
which exposes those features - including their assigned shortcuts or - as alternative - a "global" \
section in the Alt+F3 menu?</p></pre> </blockquote>
<p>On January 24th, 2016, 12:29 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;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Hi Ken,</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">I go through your feedback paragraph by paragraph. I try to \
keep it short so it might seem a bit abrupt.</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;">Why do we \
need to go so far out of our way to advertise XKill when we are capable of killing apps from the \
monitor?</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Because it would help users to find the feature. For me, it is one of those features that I \
don't look for if I don't know it exists. The system monitor which is able to kill processes is the most \
suitable place to advertise this feature.</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;">Why would \
someone who won't stop for a tooltip know to press the "V" button?</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">The \
tooltip should be used "where the function isn't clear from the label" (said Thomas Pfeiffer above). This \
implies that when the user thinks that the meaning of the button is clear he probably won't read the \
tooltip.</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;">I also dislike that it advertised as a \
feature and not a help option, and users with a crashing/frozen application will only be more frusterated \
if they think they have a solution - and are instead given a manual</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I \
disagree: if I as a user am in a situation where I need help, I am glad I get some, and be it a pointer \
to some manual. It is better than nothing. For example gparted does this when you are about to move your \
systems hard drive: it shows a message box with a short explanation and a link to a howto of how to make \
your system bootable in case of problems. Good thing for me.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">Plus: if the system or application gives \
some hint of how one can do things (better), one should be grateful and not grumpy.</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;">Imagine if every application did this - would you use a system which kept \
popping up with info boxes instead of doing the work?</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Surely \
not. I don't like that either. And I don't think if this RR was accepted as is (see also below), a \
landslide will break loose and everyone would adapt this pop-up pattern. ;-) </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;">Anyway, I would propose one of these alternative solutions: </p> \
</blockquote> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Thanks for these suggestions. I'll comment on them:</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;"> <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;">Having a tip at the bottom of the window between the task \
list and status bar which goes: "(i) You can force close a specific window by pressing #shortcut#". This \
tip could be closed/hidden permanently by the user.</li> </ul>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">This \
would advertise the feature very prominent. It could be extended with a button to trigger the feature. \
Downside: the "hide permanently" option must be properly implemented. What if I want the message \
back?</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;"> <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;">Moving the \
information to the "help" menu. Help > "How to kill a window". A little less discoverable, but much \
more appropriate. </li> </ul>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">This \
was discussed but then it would not show up in the Ctrl+Esc "System Activity" window because there is no \
Help menu.</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;"> <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;">Have it \
actually perform the function. The option will launch an [OK|Cancel] dialog ...</li> </ul>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I had \
this actually implemented. It did work fine. This is what I liked best but sadly there were technical \
concerns of calling the DBus interface of KWin (see explanations of Martin and suggestions of Thomas L in \
the first thread).</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">I agree with you that the split button is not the best solution. I also \
don't like it so much. Here is another option:</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">Add a new button right next to the "End Process..." button, \
so it would look like this:</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">"[End Process...] [More...] [Quick search]"</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">The More... button \
(instead of text it could be also an icon that looks like "more") would open a menu with currently one \
item:</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;">"Kill a window by clicking on it" which would either call the feature \
directly (if technically possible) or show a message box with the shortcut until it is technically \
possible.</li> </ul>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">What \
do you think?</p></pre> </blockquote>
<p>On January 24th, 2016, 12:35 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;">Maybe the \
question is whether KWin needs an entry in eg. the systray where it can show a window which exposes those \
features</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">A \
systray entry would be a GREAT thing! :-) Apart from the features you mentioned one could have an easy \
entry point for features like the magifier etc. Those features are really great. And there would be a \
visible entry point for the "Desktop Effects" dialog and maybe even the "Display settings". +1 from \
me!</p></pre> </blockquote>
<p>On January 24th, 2016, 1:57 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;">I'm sorry Gregor, but you still have not provided a convincing argument \
for your patch. A "More" menu with only one entry that in turn opens a dialog to explain what pressing a \
shortcut does? This may not make users grumpy, but this is exactly the kind of bloated UIs that people \
associate - negatively - with KDE software. Xkill is really only useful in very edge cases. For \
full-screen applications it's easy to find their name in the list since one usually doesn't have more \
than one application running fullscreen at the same time. If removing the decoration is the problem, then \
I'd rather show a KMessageWidget in places where the user can configure this to explain "If a borderless \
window becomes unresponsive, press <shortcut> and click it to kill it". Also: Shouldn't pressing \
Alt-F4 on an unresponsive borderless window still evoke KWin's kill feature?</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Cluttering the main UI \
with rarely-used features is bad enough. Cluttering it with explanations for rarely-used features is \
worse.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">If this was a very importantbut still hard to discover feature, I'd begrudgingly accept the \
solution to advertise it in a dialog, but for an edge-case function? No, sorry. Unless you can make a \
case where xkill is the only way to prevent data loss, I cannot accept this.</p></pre> </blockquote>
<p>On January 24th, 2016, 3:37 a.m. UTC, <b>Ken Vermette</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;">While it would be great if the feature was advertised and I understand the \
logic, the system monitor doesn't exist soley for killing applications - that's just a major use-case. If \
we extend the UI for features which the monitor doesn't even have, it's bloating it for an anti-pattern. \
While I don't expect a landslide of applications will use the anti-pattern my point is that we shouldn't \
add them knowing it's not acceptable practise, and it holds us to a lower standard when we say "good \
enough".</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">The main concern I have is the fact that it breaks the users trust in the abilities of a \
program when it outright states you can't do something through the UI. This is my biggest problem, and \
one I'd need addressed before giving a thumbs up. If I tried to use Kate and the find/replace button \
opened a popup saying "hit ctrl+r", I would drop that application faster than a bad habit, I might even \
perceive it as trying to dictate my workflow. If I were a new user to ksysguard and I encountered that \
dialog, I wouldn't use it. I wouldn't trust it to be able to fufill functionality it claims to offer, I'd \
question every UI element assuming it would let me down.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">Additionally if a user pressed this button \
or opened the menu, they have learned. Now the button is useless to that user forever. So we have a UI \
element burned into the interface which the user knows is not only useless, but will spawn a popup that \
slows them down. In the case the user forgets the shortcut it doesn't guarantee they'll remember which \
application told them the information, or where in that application it told them. </p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">It's having a "tip of the \
day" button permanently embedded in a program, but it only ever displays one tip. I'm sorry, xkill is \
great functionality, but the monitor is not the appropriate place for advertising it. As I've thought \
about it, it makes less sense to include any mention of it, I think we'd be better off with a \
desktop-level overlay or application that displays shortcuts where users can consistently reference \
important informaiton. Maybe if it's an app, add it to the favourites in launchers by default. Again, I'm \
sorry, but I just don't think this is the appropriate place to embed random information.</p></pre> \
</blockquote>
<p>On January 24th, 2016, 11:09 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;">> A "More" menu with only one entry that in turn opens \
a dialog to explain what pressing a shortcut does?
Ok, I added two new screenshots. One that shows the System Activity window which is triggered by Ctrl+Esc \
as is and the other one with an added "Tools..." button.
When the button is clicked a menu could open with these items (more than one and each of them useful for \
diagnosing the system):
* System Monitor --> opens KSysuard
* KInfoCenter --> opens KInfoCenter which also has information about Memory and Energy usage
* Run a command... --> lets the user enter a shell command
* Kill a window by clicking on it (Ctrl+Alt+Esc) --> triggers the "xkill" feature (which \
is really a KWin feature and not the actuall shell command) or shows a message box if KWin is not \
available.
What do you think?</pre>
</blockquote>
<p>On January 24th, 2016, 12:09 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;">General question to the HIG team: would you prefer the feature to be \
exposed in ksysguard or would you prefer a KWin SysTray/Statusnotifier item? (Or neither ;-)</p></pre> \
</blockquote>
<p>On January 24th, 2016, 3:35 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;"><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;">When the \
button is clicked a menu could open with these items (more than one and each of them useful for \
diagnosing the system)</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">This \
does indeed sound much more useful than a menu with only one entry, especially if the "Kill a window by \
clicking on it" optiopn would actually do that. Though we should first decide on Thomas Lübking's \
proposal.</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;">would you prefer the feature to be exposed \
in ksysguard or would you prefer a KWin SysTray/Statusnotifier item? (Or neither ;-)</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Giving \
access to KWin's useful features which are currently hiden behind a shortcut via a GUI sounds sensible to \
me. I'm not so sure if it should be in the Systray, however, since it's already overcrowded with things. \
Then again, we could just put it into a Plasmoid which users could put wherever they want - or nowhere at \
all if they don't care about the features. This should not just be informing about the shortcuts, but \
allow to actually execute the functions directly by clicking on them.</p></pre> </blockquote>
<p>On January 25th, 2016, 8:44 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;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Agreeing with Thomas L. on the general problem of KWin not having a GUI \
and that shortcuts are difficult to find. But that's a problem not unique to KWin, but in general to \
global shortcuts. Could the VDG gather some ideas how to make the shortcuts (including stuff like global \
touch gestures, etc) better available to users?</p></pre> </blockquote>
<p>On January 25th, 2016, 6:20 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;">I suggest to move the discussion and design work on the topic "KWin and \
general global shortcuts handling" to a dedicated location. If this location is known - probably opened \
by someone from the VDG? - please post back the link to it here for reference.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Meanwhile, can I get \
consent from VDG for this RR to proceed with the "Tools..." menu button as described in the recent \
discussion? (--> Ship it from VDG)</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">After that, I would continue refine the implementation of \
this RR and expect only technical issues to be discussed.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">(If the results of "KWin and general global \
shortcuts handling" become clear at some later point in time, the commited implemenation of this RR can \
be revised.)</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Please feedback for this procedure.</p></pre> </blockquote>
<p>On January 25th, 2016, 8:16 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;">I would like to add that I would like to thank you for your input to the \
discussion. For me, the current state of this RR looks much more complete and sensible than in the \
beginning.</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;">This approach makes sense. The discussion about a general "make the \
shortcuts more discoverable" solution has not started yet. I'll post a link when that happens. Since the \
entries int he Tools menu are merely handy shortcuts to other applications, if one of them isn't \
installed it simply should not show up in the menu. So make sure the menu contains only applications \
which are installed on the system. So this is a go-ahead from the VDG for the Tools menu \
solution.</p></pre> <br />
<p>- Thomas</p>
<br />
<p>On January 25th, 2016, 6:51 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, David Edmundson, Martin Gräßlin, John Tapsell, and Thomas \
Pfeiffer.</div> <div>By Gregor Mi.</div>
<p style="color: grey;"><i>Updated Jan. 25, 2016, 6:51 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">DEFERRED: \
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">DEFERRED: \
new submenu</a></li>
<li><a href="https://git.reviewboard.kde.org/media/uploaded/files/2016/01/24/8d537357-1e08-4d67-8b45-28933c1a0ccf__screenshot_20160124_115024.png">Ctrl+Esc, \
currently</a></li>
<li><a href="https://git.reviewboard.kde.org/media/uploaded/files/2016/01/24/71ebdcea-a793-460a-adb5-f05a7706f8b0__screenshot_20160124_115024-with-tools.png">Ctrl+Esc, \
with Tools... (menu contents see discussion)</a></li>
</ul>
</td>
</tr>
</table>
</div>
</body>
</html>
--===============2272826512405639280==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic