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