Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

Gregor Mi codestruct at posteo.org
Sun Jan 24 11:09:26 GMT 2016



> 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.

> 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?


- Gregor


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/#review91486
-----------------------------------------------------------


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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20160124/1021be26/attachment.htm>


More information about the kde-core-devel mailing list