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