[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