Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> 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
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> 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
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> 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
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> On Jan. 23, 2016, 6: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
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> 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
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated Jan. 24, 2016, 11:09 a.m.) Review request for KDE Base Apps, Martin Gräßlin, John Tapsell, and Thomas Pfeiffer. Changes --- add 1 screenshot and 1 mockup 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 (updated) 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
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> 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
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> 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
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> 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) 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. - 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 > >
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> 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). 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) - 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 > >
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review91486 --- > 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). - Gregor Mi 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 > >
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> On April 20, 2015, 10:36 p.m., Thomas Pfeiffer wrote: > > What would likely be confusing is that the two button modes have different > > interaction flows: The "End Process" mode requires to first select a > > process and then press the button to work, whereas the "Kill specific > > window" mode requires to first press the button and then select the window > > to kill, and users have no easy way to understand how each one works and > > why they work differently. > > > > The ellipsis in the label "End Process..." adds to that confusion. It > > indicates that further input is necessary before the action can take > > effect. While the button does open a dialog to confirm killing the selected > > process, ellipses are actually reserved for actions where a dialog asks for > > new information, such as the "Save As..." button, not for actions that > > require confirmation. > > > > To avoid this confusion, it should be possible to also click "End > > Process..." even if no processes has been selected, whuch would then ask > > the user to select the process to kill. This could theoretically be done > > similarly to the "Kill specific window" function: Click the "End > > Process..." button and then click the process in the list that you want to > > end. Alternatively, if no process had been selected when "End Process..." > > is clicked, a dialog could be opened where the process to kill would be > > selected. Of course the current flow of ending a process could and should > > still work. > > Gregor Mi wrote: > Thanks for the feedback! The ellipsis in "End Process..." is the original > design. According to your explanation this was wrong in the first place. What > about removing the ellipses in both menu items so we will end up with "End > Process" and "Kill a specific window"? > > Thomas Pfeiffer wrote: > "Kill specific window" does always need additional input until it really > does something, doesn't it? As I understood it merely changes the cursor to > the kill cursor and then the user has to select the window to kill, right? > > Gregor Mi wrote: > Erm, right. To be exact, "Kill specific window..." only shows a message > box. But in the end - after the user presses the keyboard shortcut - the user > has to select a window. So this seems to be a special case. The intention > behind all this is to increase the discoverability of the hidden xkill > feature. > > Gregor Mi wrote: > > To avoid this confusion, it should be possible to also click "End > Process..." even if no processes has been selected, whuch would then ask the > user to select the process to kill. > > If "End Process" is clicked with no processes selected, there will be a > message box which says that the user has to select one more more processes > first. > > > This could theoretically be done similarly to the "Kill specific > window" function: Click the "End Process..." button and then click the > process in the list that you want to end. > > I think "Kill specific windows" should be considered as the special case > here. Changing or extending the "End Process" workflow would introduce more > complexity to the code. > > > Alternatively, if no process had been selected when "End Process..." is > clicked, a dialog could be opened where the process to kill would be > selected. Of course the current flow of ending a p>rocess could and should > still work. > > This would be a topic for another RR. > > Summary of final changes for this RR: > > - I would change the "End Process..." to "End Process" (remove ellipsis). > Ok? > - I am not sure if the ellipsis of "Kill specific window..." should be > removed or not. > > Thomas Pfeiffer wrote: > To be honest: The more I think about this feature, the less sense it > makes to me in general. > What is XKill's usecase anyway? If an application works normally, one can > just quit it normally. If an application is frozen, KWin quite reliably > detects that when trying to close the window and allows to kill the process. > Usually "End process" is used for applications that do not have a window > (either because they don't have a GUI in the first place or because the > window has disappeared but the process is still there), in which case xkill > would not help anyway. > Yes, there may be some situations where it's useful, but they are really > corner cases. Yes, very few people know it's there, but very few people miss > the function, either. I heve never wished there was a way to hard kill a > window without using the Close button in the windeco, and I have never met > one who did. > > So we're complicating the GUI with a split button only to explain a > feature to users which the vast majority of them don't need in the first > place. > > If I have missed the "killer usecase for xkill" which makes it necessary > to make it a lot more
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> 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
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> 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
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> 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
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> 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
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> 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. 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
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> 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
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> On April 20, 2015, 10:36 p.m., Thomas Pfeiffer wrote: > > What would likely be confusing is that the two button modes have different > > interaction flows: The "End Process" mode requires to first select a > > process and then press the button to work, whereas the "Kill specific > > window" mode requires to first press the button and then select the window > > to kill, and users have no easy way to understand how each one works and > > why they work differently. > > > > The ellipsis in the label "End Process..." adds to that confusion. It > > indicates that further input is necessary before the action can take > > effect. While the button does open a dialog to confirm killing the selected > > process, ellipses are actually reserved for actions where a dialog asks for > > new information, such as the "Save As..." button, not for actions that > > require confirmation. > > > > To avoid this confusion, it should be possible to also click "End > > Process..." even if no processes has been selected, whuch would then ask > > the user to select the process to kill. This could theoretically be done > > similarly to the "Kill specific window" function: Click the "End > > Process..." button and then click the process in the list that you want to > > end. Alternatively, if no process had been selected when "End Process..." > > is clicked, a dialog could be opened where the process to kill would be > > selected. Of course the current flow of ending a process could and should > > still work. > > Gregor Mi wrote: > Thanks for the feedback! The ellipsis in "End Process..." is the original > design. According to your explanation this was wrong in the first place. What > about removing the ellipses in both menu items so we will end up with "End > Process" and "Kill a specific window"? > > Thomas Pfeiffer wrote: > "Kill specific window" does always need additional input until it really > does something, doesn't it? As I understood it merely changes the cursor to > the kill cursor and then the user has to select the window to kill, right? > > Gregor Mi wrote: > Erm, right. To be exact, "Kill specific window..." only shows a message > box. But in the end - after the user presses the keyboard shortcut - the user > has to select a window. So this seems to be a special case. The intention > behind all this is to increase the discoverability of the hidden xkill > feature. > > Gregor Mi wrote: > > To avoid this confusion, it should be possible to also click "End > Process..." even if no processes has been selected, whuch would then ask the > user to select the process to kill. > > If "End Process" is clicked with no processes selected, there will be a > message box which says that the user has to select one more more processes > first. > > > This could theoretically be done similarly to the "Kill specific > window" function: Click the "End Process..." button and then click the > process in the list that you want to end. > > I think "Kill specific windows" should be considered as the special case > here. Changing or extending the "End Process" workflow would introduce more > complexity to the code. > > > Alternatively, if no process had been selected when "End Process..." is > clicked, a dialog could be opened where the process to kill would be > selected. Of course the current flow of ending a p>rocess could and should > still work. > > This would be a topic for another RR. > > Summary of final changes for this RR: > > - I would change the "End Process..." to "End Process" (remove ellipsis). > Ok? > - I am not sure if the ellipsis of "Kill specific window..." should be > removed or not. > > Thomas Pfeiffer wrote: > To be honest: The more I think about this feature, the less sense it > makes to me in general. > What is XKill's usecase anyway? If an application works normally, one can > just quit it normally. If an application is frozen, KWin quite reliably > detects that when trying to close the window and allows to kill the process. > Usually "End process" is used for applications that do not have a window > (either because they don't have a GUI in the first place or because the > window has disappeared but the process is still there), in which case xkill > would not help anyway. > Yes, there may be some situations where it's useful, but they are really > corner cases. Yes, very few people know it's there, but very few people miss > the function, either. I heve never wished there was a way to hard kill a > window without using the Close button in the windeco, and I have never met > one who did. > > So we're complicating the GUI with a split button only to explain a > feature to users which the vast majority of them don't need in the first > place. > > If I have missed the "killer usecase for xkill" which makes it necessary > to make it a lot more
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> On April 20, 2015, 10:36 p.m., Thomas Pfeiffer wrote: > > What would likely be confusing is that the two button modes have different > > interaction flows: The "End Process" mode requires to first select a > > process and then press the button to work, whereas the "Kill specific > > window" mode requires to first press the button and then select the window > > to kill, and users have no easy way to understand how each one works and > > why they work differently. > > > > The ellipsis in the label "End Process..." adds to that confusion. It > > indicates that further input is necessary before the action can take > > effect. While the button does open a dialog to confirm killing the selected > > process, ellipses are actually reserved for actions where a dialog asks for > > new information, such as the "Save As..." button, not for actions that > > require confirmation. > > > > To avoid this confusion, it should be possible to also click "End > > Process..." even if no processes has been selected, whuch would then ask > > the user to select the process to kill. This could theoretically be done > > similarly to the "Kill specific window" function: Click the "End > > Process..." button and then click the process in the list that you want to > > end. Alternatively, if no process had been selected when "End Process..." > > is clicked, a dialog could be opened where the process to kill would be > > selected. Of course the current flow of ending a process could and should > > still work. > > Gregor Mi wrote: > Thanks for the feedback! The ellipsis in "End Process..." is the original > design. According to your explanation this was wrong in the first place. What > about removing the ellipses in both menu items so we will end up with "End > Process" and "Kill a specific window"? > > Thomas Pfeiffer wrote: > "Kill specific window" does always need additional input until it really > does something, doesn't it? As I understood it merely changes the cursor to > the kill cursor and then the user has to select the window to kill, right? > > Gregor Mi wrote: > Erm, right. To be exact, "Kill specific window..." only shows a message > box. But in the end - after the user presses the keyboard shortcut - the user > has to select a window. So this seems to be a special case. The intention > behind all this is to increase the discoverability of the hidden xkill > feature. > > Gregor Mi wrote: > > To avoid this confusion, it should be possible to also click "End > Process..." even if no processes has been selected, whuch would then ask the > user to select the process to kill. > > If "End Process" is clicked with no processes selected, there will be a > message box which says that the user has to select one more more processes > first. > > > This could theoretically be done similarly to the "Kill specific > window" function: Click the "End Process..." button and then click the > process in the list that you want to end. > > I think "Kill specific windows" should be considered as the special case > here. Changing or extending the "End Process" workflow would introduce more > complexity to the code. > > > Alternatively, if no process had been selected when "End Process..." is > clicked, a dialog could be opened where the process to kill would be > selected. Of course the current flow of ending a p>rocess could and should > still work. > > This would be a topic for another RR. > > Summary of final changes for this RR: > > - I would change the "End Process..." to "End Process" (remove ellipsis). > Ok? > - I am not sure if the ellipsis of "Kill specific window..." should be > removed or not. > > Thomas Pfeiffer wrote: > To be honest: The more I think about this feature, the less sense it > makes to me in general. > What is XKill's usecase anyway? If an application works normally, one can > just quit it normally. If an application is frozen, KWin quite reliably > detects that when trying to close the window and allows to kill the process. > Usually "End process" is used for applications that do not have a window > (either because they don't have a GUI in the first place or because the > window has disappeared but the process is still there), in which case xkill > would not help anyway. > Yes, there may be some situations where it's useful, but they are really > corner cases. Yes, very few people know it's there, but very few people miss > the function, either. I heve never wished there was a way to hard kill a > window without using the Close button in the windeco, and I have never met > one who did. > > So we're complicating the GUI with a split button only to explain a > feature to users which the vast majority of them don't need in the first > place. > > If I have missed the "killer usecase for xkill" which makes it necessary > to make it a lot more
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On April 20, 2015, 10:36 p.m., Thomas Pfeiffer wrote: What would likely be confusing is that the two button modes have different interaction flows: The End Process mode requires to first select a process and then press the button to work, whereas the Kill specific window mode requires to first press the button and then select the window to kill, and users have no easy way to understand how each one works and why they work differently. The ellipsis in the label End Process... adds to that confusion. It indicates that further input is necessary before the action can take effect. While the button does open a dialog to confirm killing the selected process, ellipses are actually reserved for actions where a dialog asks for new information, such as the Save As... button, not for actions that require confirmation. To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. Gregor Mi wrote: Thanks for the feedback! The ellipsis in End Process... is the original design. According to your explanation this was wrong in the first place. What about removing the ellipses in both menu items so we will end up with End Process and Kill a specific window? Thomas Pfeiffer wrote: Kill specific window does always need additional input until it really does something, doesn't it? As I understood it merely changes the cursor to the kill cursor and then the user has to select the window to kill, right? Gregor Mi wrote: Erm, right. To be exact, Kill specific window... only shows a message box. But in the end - after the user presses the keyboard shortcut - the user has to select a window. So this seems to be a special case. The intention behind all this is to increase the discoverability of the hidden xkill feature. Gregor Mi wrote: To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. If End Process is clicked with no processes selected, there will be a message box which says that the user has to select one more more processes first. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. I think Kill specific windows should be considered as the special case here. Changing or extending the End Process workflow would introduce more complexity to the code. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. This would be a topic for another RR. Summary of final changes for this RR: - I would change the End Process... to End Process (remove ellipsis). Ok? - I am not sure if the ellipsis of Kill specific window... should be removed or not. Thomas Pfeiffer wrote: To be honest: The more I think about this feature, the less sense it makes to me in general. What is XKill's usecase anyway? If an application works normally, one can just quit it normally. If an application is frozen, KWin quite reliably detects that when trying to close the window and allows to kill the process. Usually End process is used for applications that do not have a window (either because they don't have a GUI in the first place or because the window has disappeared but the process is still there), in which case xkill would not help anyway. Yes, there may be some situations where it's useful, but they are really corner cases. Yes, very few people know it's there, but very few people miss the function, either. I heve never wished there was a way to hard kill a window without using the Close button in the windeco, and I have never met one who did. So we're complicating the GUI with a split button only to explain a feature to users which the vast majority of them don't need in the first place. If I have missed the killer usecase for xkill which makes it necessary to make it a lot more visible, please tell me about it. Martin Gräßlin wrote: If I have missed the killer usecase for xkill which makes it necessary to make it a lot more visible, please
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On April 20, 2015, 10:36 p.m., Thomas Pfeiffer wrote: What would likely be confusing is that the two button modes have different interaction flows: The End Process mode requires to first select a process and then press the button to work, whereas the Kill specific window mode requires to first press the button and then select the window to kill, and users have no easy way to understand how each one works and why they work differently. The ellipsis in the label End Process... adds to that confusion. It indicates that further input is necessary before the action can take effect. While the button does open a dialog to confirm killing the selected process, ellipses are actually reserved for actions where a dialog asks for new information, such as the Save As... button, not for actions that require confirmation. To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. Gregor Mi wrote: Thanks for the feedback! The ellipsis in End Process... is the original design. According to your explanation this was wrong in the first place. What about removing the ellipses in both menu items so we will end up with End Process and Kill a specific window? Thomas Pfeiffer wrote: Kill specific window does always need additional input until it really does something, doesn't it? As I understood it merely changes the cursor to the kill cursor and then the user has to select the window to kill, right? Gregor Mi wrote: Erm, right. To be exact, Kill specific window... only shows a message box. But in the end - after the user presses the keyboard shortcut - the user has to select a window. So this seems to be a special case. The intention behind all this is to increase the discoverability of the hidden xkill feature. Gregor Mi wrote: To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. If End Process is clicked with no processes selected, there will be a message box which says that the user has to select one more more processes first. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. I think Kill specific windows should be considered as the special case here. Changing or extending the End Process workflow would introduce more complexity to the code. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. This would be a topic for another RR. Summary of final changes for this RR: - I would change the End Process... to End Process (remove ellipsis). Ok? - I am not sure if the ellipsis of Kill specific window... should be removed or not. Thomas Pfeiffer wrote: To be honest: The more I think about this feature, the less sense it makes to me in general. What is XKill's usecase anyway? If an application works normally, one can just quit it normally. If an application is frozen, KWin quite reliably detects that when trying to close the window and allows to kill the process. Usually End process is used for applications that do not have a window (either because they don't have a GUI in the first place or because the window has disappeared but the process is still there), in which case xkill would not help anyway. Yes, there may be some situations where it's useful, but they are really corner cases. Yes, very few people know it's there, but very few people miss the function, either. I heve never wished there was a way to hard kill a window without using the Close button in the windeco, and I have never met one who did. So we're complicating the GUI with a split button only to explain a feature to users which the vast majority of them don't need in the first place. If I have missed the killer usecase for xkill which makes it necessary to make it a lot more visible, please tell me about it. Martin Gräßlin wrote: If I have missed the killer usecase for xkill which makes it necessary to make it a lot more visible, please
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On April 20, 2015, 10:36 p.m., Thomas Pfeiffer wrote: What would likely be confusing is that the two button modes have different interaction flows: The End Process mode requires to first select a process and then press the button to work, whereas the Kill specific window mode requires to first press the button and then select the window to kill, and users have no easy way to understand how each one works and why they work differently. The ellipsis in the label End Process... adds to that confusion. It indicates that further input is necessary before the action can take effect. While the button does open a dialog to confirm killing the selected process, ellipses are actually reserved for actions where a dialog asks for new information, such as the Save As... button, not for actions that require confirmation. To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. Gregor Mi wrote: Thanks for the feedback! The ellipsis in End Process... is the original design. According to your explanation this was wrong in the first place. What about removing the ellipses in both menu items so we will end up with End Process and Kill a specific window? Thomas Pfeiffer wrote: Kill specific window does always need additional input until it really does something, doesn't it? As I understood it merely changes the cursor to the kill cursor and then the user has to select the window to kill, right? Gregor Mi wrote: Erm, right. To be exact, Kill specific window... only shows a message box. But in the end - after the user presses the keyboard shortcut - the user has to select a window. So this seems to be a special case. The intention behind all this is to increase the discoverability of the hidden xkill feature. Gregor Mi wrote: To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. If End Process is clicked with no processes selected, there will be a message box which says that the user has to select one more more processes first. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. I think Kill specific windows should be considered as the special case here. Changing or extending the End Process workflow would introduce more complexity to the code. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. This would be a topic for another RR. Summary of final changes for this RR: - I would change the End Process... to End Process (remove ellipsis). Ok? - I am not sure if the ellipsis of Kill specific window... should be removed or not. Thomas Pfeiffer wrote: To be honest: The more I think about this feature, the less sense it makes to me in general. What is XKill's usecase anyway? If an application works normally, one can just quit it normally. If an application is frozen, KWin quite reliably detects that when trying to close the window and allows to kill the process. Usually End process is used for applications that do not have a window (either because they don't have a GUI in the first place or because the window has disappeared but the process is still there), in which case xkill would not help anyway. Yes, there may be some situations where it's useful, but they are really corner cases. Yes, very few people know it's there, but very few people miss the function, either. I heve never wished there was a way to hard kill a window without using the Close button in the windeco, and I have never met one who did. So we're complicating the GUI with a split button only to explain a feature to users which the vast majority of them don't need in the first place. If I have missed the killer usecase for xkill which makes it necessary to make it a lot more visible, please tell me about it. Martin Gräßlin wrote: If I have missed the killer usecase for xkill which makes it necessary to make it a lot more visible, please
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On April 20, 2015, 10:36 p.m., Thomas Pfeiffer wrote: What would likely be confusing is that the two button modes have different interaction flows: The End Process mode requires to first select a process and then press the button to work, whereas the Kill specific window mode requires to first press the button and then select the window to kill, and users have no easy way to understand how each one works and why they work differently. The ellipsis in the label End Process... adds to that confusion. It indicates that further input is necessary before the action can take effect. While the button does open a dialog to confirm killing the selected process, ellipses are actually reserved for actions where a dialog asks for new information, such as the Save As... button, not for actions that require confirmation. To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. Gregor Mi wrote: Thanks for the feedback! The ellipsis in End Process... is the original design. According to your explanation this was wrong in the first place. What about removing the ellipses in both menu items so we will end up with End Process and Kill a specific window? Thomas Pfeiffer wrote: Kill specific window does always need additional input until it really does something, doesn't it? As I understood it merely changes the cursor to the kill cursor and then the user has to select the window to kill, right? Gregor Mi wrote: Erm, right. To be exact, Kill specific window... only shows a message box. But in the end - after the user presses the keyboard shortcut - the user has to select a window. So this seems to be a special case. The intention behind all this is to increase the discoverability of the hidden xkill feature. Gregor Mi wrote: To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. If End Process is clicked with no processes selected, there will be a message box which says that the user has to select one more more processes first. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. I think Kill specific windows should be considered as the special case here. Changing or extending the End Process workflow would introduce more complexity to the code. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. This would be a topic for another RR. Summary of final changes for this RR: - I would change the End Process... to End Process (remove ellipsis). Ok? - I am not sure if the ellipsis of Kill specific window... should be removed or not. Thomas Pfeiffer wrote: To be honest: The more I think about this feature, the less sense it makes to me in general. What is XKill's usecase anyway? If an application works normally, one can just quit it normally. If an application is frozen, KWin quite reliably detects that when trying to close the window and allows to kill the process. Usually End process is used for applications that do not have a window (either because they don't have a GUI in the first place or because the window has disappeared but the process is still there), in which case xkill would not help anyway. Yes, there may be some situations where it's useful, but they are really corner cases. Yes, very few people know it's there, but very few people miss the function, either. I heve never wished there was a way to hard kill a window without using the Close button in the windeco, and I have never met one who did. So we're complicating the GUI with a split button only to explain a feature to users which the vast majority of them don't need in the first place. If I have missed the killer usecase for xkill which makes it necessary to make it a lot more visible, please tell me about it. Martin Gräßlin wrote: If I have missed the killer usecase for xkill which makes it necessary to make it a lot more visible, please
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On April 20, 2015, 10:36 p.m., Thomas Pfeiffer wrote: What would likely be confusing is that the two button modes have different interaction flows: The End Process mode requires to first select a process and then press the button to work, whereas the Kill specific window mode requires to first press the button and then select the window to kill, and users have no easy way to understand how each one works and why they work differently. The ellipsis in the label End Process... adds to that confusion. It indicates that further input is necessary before the action can take effect. While the button does open a dialog to confirm killing the selected process, ellipses are actually reserved for actions where a dialog asks for new information, such as the Save As... button, not for actions that require confirmation. To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. Gregor Mi wrote: Thanks for the feedback! The ellipsis in End Process... is the original design. According to your explanation this was wrong in the first place. What about removing the ellipses in both menu items so we will end up with End Process and Kill a specific window? Thomas Pfeiffer wrote: Kill specific window does always need additional input until it really does something, doesn't it? As I understood it merely changes the cursor to the kill cursor and then the user has to select the window to kill, right? Gregor Mi wrote: Erm, right. To be exact, Kill specific window... only shows a message box. But in the end - after the user presses the keyboard shortcut - the user has to select a window. So this seems to be a special case. The intention behind all this is to increase the discoverability of the hidden xkill feature. Gregor Mi wrote: To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. If End Process is clicked with no processes selected, there will be a message box which says that the user has to select one more more processes first. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. I think Kill specific windows should be considered as the special case here. Changing or extending the End Process workflow would introduce more complexity to the code. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. This would be a topic for another RR. Summary of final changes for this RR: - I would change the End Process... to End Process (remove ellipsis). Ok? - I am not sure if the ellipsis of Kill specific window... should be removed or not. Thomas Pfeiffer wrote: To be honest: The more I think about this feature, the less sense it makes to me in general. What is XKill's usecase anyway? If an application works normally, one can just quit it normally. If an application is frozen, KWin quite reliably detects that when trying to close the window and allows to kill the process. Usually End process is used for applications that do not have a window (either because they don't have a GUI in the first place or because the window has disappeared but the process is still there), in which case xkill would not help anyway. Yes, there may be some situations where it's useful, but they are really corner cases. Yes, very few people know it's there, but very few people miss the function, either. I heve never wished there was a way to hard kill a window without using the Close button in the windeco, and I have never met one who did. So we're complicating the GUI with a split button only to explain a feature to users which the vast majority of them don't need in the first place. If I have missed the killer usecase for xkill which makes it necessary to make it a lot more visible, please tell me about it. Martin Gräßlin wrote: If I have missed the killer usecase for xkill which makes it necessary to make it a lot more visible, please
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On April 20, 2015, 10:36 p.m., Thomas Pfeiffer wrote: What would likely be confusing is that the two button modes have different interaction flows: The End Process mode requires to first select a process and then press the button to work, whereas the Kill specific window mode requires to first press the button and then select the window to kill, and users have no easy way to understand how each one works and why they work differently. The ellipsis in the label End Process... adds to that confusion. It indicates that further input is necessary before the action can take effect. While the button does open a dialog to confirm killing the selected process, ellipses are actually reserved for actions where a dialog asks for new information, such as the Save As... button, not for actions that require confirmation. To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. Gregor Mi wrote: Thanks for the feedback! The ellipsis in End Process... is the original design. According to your explanation this was wrong in the first place. What about removing the ellipses in both menu items so we will end up with End Process and Kill a specific window? Thomas Pfeiffer wrote: Kill specific window does always need additional input until it really does something, doesn't it? As I understood it merely changes the cursor to the kill cursor and then the user has to select the window to kill, right? Gregor Mi wrote: Erm, right. To be exact, Kill specific window... only shows a message box. But in the end - after the user presses the keyboard shortcut - the user has to select a window. So this seems to be a special case. The intention behind all this is to increase the discoverability of the hidden xkill feature. Gregor Mi wrote: To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. If End Process is clicked with no processes selected, there will be a message box which says that the user has to select one more more processes first. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. I think Kill specific windows should be considered as the special case here. Changing or extending the End Process workflow would introduce more complexity to the code. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. This would be a topic for another RR. Summary of final changes for this RR: - I would change the End Process... to End Process (remove ellipsis). Ok? - I am not sure if the ellipsis of Kill specific window... should be removed or not. Thomas Pfeiffer wrote: To be honest: The more I think about this feature, the less sense it makes to me in general. What is XKill's usecase anyway? If an application works normally, one can just quit it normally. If an application is frozen, KWin quite reliably detects that when trying to close the window and allows to kill the process. Usually End process is used for applications that do not have a window (either because they don't have a GUI in the first place or because the window has disappeared but the process is still there), in which case xkill would not help anyway. Yes, there may be some situations where it's useful, but they are really corner cases. Yes, very few people know it's there, but very few people miss the function, either. I heve never wished there was a way to hard kill a window without using the Close button in the windeco, and I have never met one who did. So we're complicating the GUI with a split button only to explain a feature to users which the vast majority of them don't need in the first place. If I have missed the killer usecase for xkill which makes it necessary to make it a lot more visible, please tell me about it. Martin Gräßlin wrote: If I have missed the killer usecase for xkill which makes it necessary to make it a lot more visible, please
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On April 21, 2015, 12:36 a.m., Thomas Pfeiffer wrote: What would likely be confusing is that the two button modes have different interaction flows: The End Process mode requires to first select a process and then press the button to work, whereas the Kill specific window mode requires to first press the button and then select the window to kill, and users have no easy way to understand how each one works and why they work differently. The ellipsis in the label End Process... adds to that confusion. It indicates that further input is necessary before the action can take effect. While the button does open a dialog to confirm killing the selected process, ellipses are actually reserved for actions where a dialog asks for new information, such as the Save As... button, not for actions that require confirmation. To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. Gregor Mi wrote: Thanks for the feedback! The ellipsis in End Process... is the original design. According to your explanation this was wrong in the first place. What about removing the ellipses in both menu items so we will end up with End Process and Kill a specific window? Thomas Pfeiffer wrote: Kill specific window does always need additional input until it really does something, doesn't it? As I understood it merely changes the cursor to the kill cursor and then the user has to select the window to kill, right? Gregor Mi wrote: Erm, right. To be exact, Kill specific window... only shows a message box. But in the end - after the user presses the keyboard shortcut - the user has to select a window. So this seems to be a special case. The intention behind all this is to increase the discoverability of the hidden xkill feature. Gregor Mi wrote: To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. If End Process is clicked with no processes selected, there will be a message box which says that the user has to select one more more processes first. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. I think Kill specific windows should be considered as the special case here. Changing or extending the End Process workflow would introduce more complexity to the code. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. This would be a topic for another RR. Summary of final changes for this RR: - I would change the End Process... to End Process (remove ellipsis). Ok? - I am not sure if the ellipsis of Kill specific window... should be removed or not. Thomas Pfeiffer wrote: To be honest: The more I think about this feature, the less sense it makes to me in general. What is XKill's usecase anyway? If an application works normally, one can just quit it normally. If an application is frozen, KWin quite reliably detects that when trying to close the window and allows to kill the process. Usually End process is used for applications that do not have a window (either because they don't have a GUI in the first place or because the window has disappeared but the process is still there), in which case xkill would not help anyway. Yes, there may be some situations where it's useful, but they are really corner cases. Yes, very few people know it's there, but very few people miss the function, either. I heve never wished there was a way to hard kill a window without using the Close button in the windeco, and I have never met one who did. So we're complicating the GUI with a split button only to explain a feature to users which the vast majority of them don't need in the first place. If I have missed the killer usecase for xkill which makes it necessary to make it a lot more visible, please tell me about it. If I have missed the killer usecase for xkill which makes it necessary to make it a lot more visible, please tell me about it. well, assume
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On April 20, 2015, 10:36 nachm., Thomas Pfeiffer wrote: What would likely be confusing is that the two button modes have different interaction flows: The End Process mode requires to first select a process and then press the button to work, whereas the Kill specific window mode requires to first press the button and then select the window to kill, and users have no easy way to understand how each one works and why they work differently. The ellipsis in the label End Process... adds to that confusion. It indicates that further input is necessary before the action can take effect. While the button does open a dialog to confirm killing the selected process, ellipses are actually reserved for actions where a dialog asks for new information, such as the Save As... button, not for actions that require confirmation. To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. Gregor Mi wrote: Thanks for the feedback! The ellipsis in End Process... is the original design. According to your explanation this was wrong in the first place. What about removing the ellipses in both menu items so we will end up with End Process and Kill a specific window? Thomas Pfeiffer wrote: Kill specific window does always need additional input until it really does something, doesn't it? As I understood it merely changes the cursor to the kill cursor and then the user has to select the window to kill, right? Gregor Mi wrote: Erm, right. To be exact, Kill specific window... only shows a message box. But in the end - after the user presses the keyboard shortcut - the user has to select a window. So this seems to be a special case. The intention behind all this is to increase the discoverability of the hidden xkill feature. Gregor Mi wrote: To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. If End Process is clicked with no processes selected, there will be a message box which says that the user has to select one more more processes first. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. I think Kill specific windows should be considered as the special case here. Changing or extending the End Process workflow would introduce more complexity to the code. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. This would be a topic for another RR. Summary of final changes for this RR: - I would change the End Process... to End Process (remove ellipsis). Ok? - I am not sure if the ellipsis of Kill specific window... should be removed or not. Thomas Pfeiffer wrote: To be honest: The more I think about this feature, the less sense it makes to me in general. What is XKill's usecase anyway? If an application works normally, one can just quit it normally. If an application is frozen, KWin quite reliably detects that when trying to close the window and allows to kill the process. Usually End process is used for applications that do not have a window (either because they don't have a GUI in the first place or because the window has disappeared but the process is still there), in which case xkill would not help anyway. Yes, there may be some situations where it's useful, but they are really corner cases. Yes, very few people know it's there, but very few people miss the function, either. I heve never wished there was a way to hard kill a window without using the Close button in the windeco, and I have never met one who did. So we're complicating the GUI with a split button only to explain a feature to users which the vast majority of them don't need in the first place. If I have missed the killer usecase for xkill which makes it necessary to make it a lot more visible, please tell me about it. Martin Gräßlin wrote: If I have missed the killer usecase for xkill which makes it necessary to make it a lot more visible, please
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On April 20, 2015, 10:36 nachm., Thomas Pfeiffer wrote: What would likely be confusing is that the two button modes have different interaction flows: The End Process mode requires to first select a process and then press the button to work, whereas the Kill specific window mode requires to first press the button and then select the window to kill, and users have no easy way to understand how each one works and why they work differently. The ellipsis in the label End Process... adds to that confusion. It indicates that further input is necessary before the action can take effect. While the button does open a dialog to confirm killing the selected process, ellipses are actually reserved for actions where a dialog asks for new information, such as the Save As... button, not for actions that require confirmation. To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. Gregor Mi wrote: Thanks for the feedback! The ellipsis in End Process... is the original design. According to your explanation this was wrong in the first place. What about removing the ellipses in both menu items so we will end up with End Process and Kill a specific window? Thomas Pfeiffer wrote: Kill specific window does always need additional input until it really does something, doesn't it? As I understood it merely changes the cursor to the kill cursor and then the user has to select the window to kill, right? Gregor Mi wrote: Erm, right. To be exact, Kill specific window... only shows a message box. But in the end - after the user presses the keyboard shortcut - the user has to select a window. So this seems to be a special case. The intention behind all this is to increase the discoverability of the hidden xkill feature. Gregor Mi wrote: To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. If End Process is clicked with no processes selected, there will be a message box which says that the user has to select one more more processes first. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. I think Kill specific windows should be considered as the special case here. Changing or extending the End Process workflow would introduce more complexity to the code. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. This would be a topic for another RR. Summary of final changes for this RR: - I would change the End Process... to End Process (remove ellipsis). Ok? - I am not sure if the ellipsis of Kill specific window... should be removed or not. Thomas Pfeiffer wrote: To be honest: The more I think about this feature, the less sense it makes to me in general. What is XKill's usecase anyway? If an application works normally, one can just quit it normally. If an application is frozen, KWin quite reliably detects that when trying to close the window and allows to kill the process. Usually End process is used for applications that do not have a window (either because they don't have a GUI in the first place or because the window has disappeared but the process is still there), in which case xkill would not help anyway. Yes, there may be some situations where it's useful, but they are really corner cases. Yes, very few people know it's there, but very few people miss the function, either. I heve never wished there was a way to hard kill a window without using the Close button in the windeco, and I have never met one who did. So we're complicating the GUI with a split button only to explain a feature to users which the vast majority of them don't need in the first place. If I have missed the killer usecase for xkill which makes it necessary to make it a lot more visible, please tell me about it. Martin Gräßlin wrote: If I have missed the killer usecase for xkill which makes it necessary to make it a lot more visible, please
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On April 20, 2015, 10:36 p.m., Thomas Pfeiffer wrote: What would likely be confusing is that the two button modes have different interaction flows: The End Process mode requires to first select a process and then press the button to work, whereas the Kill specific window mode requires to first press the button and then select the window to kill, and users have no easy way to understand how each one works and why they work differently. The ellipsis in the label End Process... adds to that confusion. It indicates that further input is necessary before the action can take effect. While the button does open a dialog to confirm killing the selected process, ellipses are actually reserved for actions where a dialog asks for new information, such as the Save As... button, not for actions that require confirmation. To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. Gregor Mi wrote: Thanks for the feedback! The ellipsis in End Process... is the original design. According to your explanation this was wrong in the first place. What about removing the ellipses in both menu items so we will end up with End Process and Kill a specific window? Thomas Pfeiffer wrote: Kill specific window does always need additional input until it really does something, doesn't it? As I understood it merely changes the cursor to the kill cursor and then the user has to select the window to kill, right? Gregor Mi wrote: Erm, right. To be exact, Kill specific window... only shows a message box. But in the end - after the user presses the keyboard shortcut - the user has to select a window. So this seems to be a special case. The intention behind all this is to increase the discoverability of the hidden xkill feature. Gregor Mi wrote: To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. If End Process is clicked with no processes selected, there will be a message box which says that the user has to select one more more processes first. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. I think Kill specific windows should be considered as the special case here. Changing or extending the End Process workflow would introduce more complexity to the code. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. This would be a topic for another RR. Summary of final changes for this RR: - I would change the End Process... to End Process (remove ellipsis). Ok? - I am not sure if the ellipsis of Kill specific window... should be removed or not. To be honest: The more I think about this feature, the less sense it makes to me in general. What is XKill's usecase anyway? If an application works normally, one can just quit it normally. If an application is frozen, KWin quite reliably detects that when trying to close the window and allows to kill the process. Usually End process is used for applications that do not have a window (either because they don't have a GUI in the first place or because the window has disappeared but the process is still there), in which case xkill would not help anyway. Yes, there may be some situations where it's useful, but they are really corner cases. Yes, very few people know it's there, but very few people miss the function, either. I heve never wished there was a way to hard kill a window without using the Close button in the windeco, and I have never met one who did. So we're complicating the GUI with a split button only to explain a feature to users which the vast majority of them don't need in the first place. If I have missed the killer usecase for xkill which makes it necessary to make it a lot more visible, please tell me about it. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review79262
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On April 20, 2015, 10:36 p.m., Thomas Pfeiffer wrote: What would likely be confusing is that the two button modes have different interaction flows: The End Process mode requires to first select a process and then press the button to work, whereas the Kill specific window mode requires to first press the button and then select the window to kill, and users have no easy way to understand how each one works and why they work differently. The ellipsis in the label End Process... adds to that confusion. It indicates that further input is necessary before the action can take effect. While the button does open a dialog to confirm killing the selected process, ellipses are actually reserved for actions where a dialog asks for new information, such as the Save As... button, not for actions that require confirmation. To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. Gregor Mi wrote: Thanks for the feedback! The ellipsis in End Process... is the original design. According to your explanation this was wrong in the first place. What about removing the ellipses in both menu items so we will end up with End Process and Kill a specific window? Thomas Pfeiffer wrote: Kill specific window does always need additional input until it really does something, doesn't it? As I understood it merely changes the cursor to the kill cursor and then the user has to select the window to kill, right? Gregor Mi wrote: Erm, right. To be exact, Kill specific window... only shows a message box. But in the end - after the user presses the keyboard shortcut - the user has to select a window. So this seems to be a special case. The intention behind all this is to increase the discoverability of the hidden xkill feature. To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. If End Process is clicked with no processes selected, there will be a message box which says that the user has to select one more more processes first. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. I think Kill specific windows should be considered as the special case here. Changing or extending the End Process workflow would introduce more complexity to the code. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. This would be a topic for another RR. Summary of final changes for this RR: - I would change the End Process... to End Process (remove ellipsis). Ok? - I am not sure if the ellipsis of Kill specific window... should be removed or not. - Gregor --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review79262 --- 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
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On April 20, 2015, 10:36 p.m., Thomas Pfeiffer wrote: What would likely be confusing is that the two button modes have different interaction flows: The End Process mode requires to first select a process and then press the button to work, whereas the Kill specific window mode requires to first press the button and then select the window to kill, and users have no easy way to understand how each one works and why they work differently. The ellipsis in the label End Process... adds to that confusion. It indicates that further input is necessary before the action can take effect. While the button does open a dialog to confirm killing the selected process, ellipses are actually reserved for actions where a dialog asks for new information, such as the Save As... button, not for actions that require confirmation. To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. Gregor Mi wrote: Thanks for the feedback! The ellipsis in End Process... is the original design. According to your explanation this was wrong in the first place. What about removing the ellipses in both menu items so we will end up with End Process and Kill a specific window? Thomas Pfeiffer wrote: Kill specific window does always need additional input until it really does something, doesn't it? As I understood it merely changes the cursor to the kill cursor and then the user has to select the window to kill, right? Erm, right. To be exact, Kill specific window... only shows a message box. But in the end - after the user presses the keyboard shortcut - the user has to select a window. So this seems to be a special case. The intention behind all this is to increase the discoverability of the hidden xkill feature. - Gregor --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review79262 --- 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
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- 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. Changes --- Remove message box screenshot because the text changed. There are two different texts depending if KWin is used or not. Message box without KWin: ``` Typically, the kill window method can be invoked with the global shortcut Ctrl+Alt+Esc. The mouse cursor will then change into a deadly skull or some other pirate symbol. If you left-click on a window, the corresponding process will be killed - and unsaved data be lost. Typically, with right-click you can abort. ``` Message box text with KWin: ``` The kill window method can be invoked with a global shortcut which is currently set to: Ctrl+Alt+Esc The mouse cursor will then change into a deadly skull or some other pirate symbol. If you left-click on a window, the corresponding process will be killed - and unsaved data be lost. With right-click or the Esc key you can abort. ``` 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 (updated) 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
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On April 20, 2015, 10:36 p.m., Thomas Pfeiffer wrote: What would likely be confusing is that the two button modes have different interaction flows: The End Process mode requires to first select a process and then press the button to work, whereas the Kill specific window mode requires to first press the button and then select the window to kill, and users have no easy way to understand how each one works and why they work differently. The ellipsis in the label End Process... adds to that confusion. It indicates that further input is necessary before the action can take effect. While the button does open a dialog to confirm killing the selected process, ellipses are actually reserved for actions where a dialog asks for new information, such as the Save As... button, not for actions that require confirmation. To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. Thanks for the feedback! The ellipsis in End Process... is the original design. According to your explanation this was wrong in the first place. What about removing the ellipses in both menu items so we will end up with End Process and Kill a specific window? - Gregor --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review79262 --- 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
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On April 20, 2015, 10:36 p.m., Thomas Pfeiffer wrote: What would likely be confusing is that the two button modes have different interaction flows: The End Process mode requires to first select a process and then press the button to work, whereas the Kill specific window mode requires to first press the button and then select the window to kill, and users have no easy way to understand how each one works and why they work differently. The ellipsis in the label End Process... adds to that confusion. It indicates that further input is necessary before the action can take effect. While the button does open a dialog to confirm killing the selected process, ellipses are actually reserved for actions where a dialog asks for new information, such as the Save As... button, not for actions that require confirmation. To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. Gregor Mi wrote: Thanks for the feedback! The ellipsis in End Process... is the original design. According to your explanation this was wrong in the first place. What about removing the ellipses in both menu items so we will end up with End Process and Kill a specific window? Kill specific window does always need additional input until it really does something, doesn't it? As I understood it merely changes the cursor to the kill cursor and then the user has to select the window to kill, right? - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review79262 --- 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
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review79262 --- What would likely be confusing is that the two button modes have different interaction flows: The End Process mode requires to first select a process and then press the button to work, whereas the Kill specific window mode requires to first press the button and then select the window to kill, and users have no easy way to understand how each one works and why they work differently. The ellipsis in the label End Process... adds to that confusion. It indicates that further input is necessary before the action can take effect. While the button does open a dialog to confirm killing the selected process, ellipses are actually reserved for actions where a dialog asks for new information, such as the Save As... button, not for actions that require confirmation. To avoid this confusion, it should be possible to also click End Process... even if no processes has been selected, whuch would then ask the user to select the process to kill. This could theoretically be done similarly to the Kill specific window function: Click the End Process... button and then click the process in the list that you want to end. Alternatively, if no process had been selected when End Process... is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. - Thomas Pfeiffer 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
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On April 16, 2015, 3:14 p.m., Martin Gräßlin wrote: CMakeLists.txt, lines 22-33 https://git.reviewboard.kde.org/r/122249/diff/9/?file=360665#file360665line22 do we still need all those? I only see GlobalAccel used as a new dependency or am I missing something? Previously those were all in one line. Effectively only GlobalAccel was added. - Gregor --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review79059 --- On April 17, 2015, 7:25 a.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated April 17, 2015, 7:25 a.m.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. 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 new message box https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/5565e806-bf16-4ef2-89f2-ac122bf3421c__messagebox.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review79097 --- I'm still not sure about the text for the message box: could you please add Thomas Pfeiffer from Usability team to the review to get him comment on it? - Martin Gräßlin On April 17, 2015, 9:25 a.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated April 17, 2015, 9:25 a.m.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. 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 new message box https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/5565e806-bf16-4ef2-89f2-ac122bf3421c__messagebox.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated April 17, 2015, 7:25 a.m.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. Changes --- - add translation hint - fiex message box text - remove empty line 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 (updated) - 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 new message box https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/5565e806-bf16-4ef2-89f2-ac122bf3421c__messagebox.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On April 17, 2015, 7:31 a.m., Martin Gräßlin wrote: I'm still not sure about the text for the message box: could you please add Thomas Pfeiffer from Usability team to the review to get him comment on it? Sure. I'll add him. - Gregor --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review79097 --- On April 17, 2015, 7:25 a.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated April 17, 2015, 7:25 a.m.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. 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 new message box https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/5565e806-bf16-4ef2-89f2-ac122bf3421c__messagebox.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On April 17, 2015, 7:31 a.m., Martin Gräßlin wrote: I'm still not sure about the text for the message box: could you please add Thomas Pfeiffer from Usability team to the review to get him comment on it? Gregor Mi wrote: Sure. I'll add him. I updated the text. Message box without KWin: ``` Typically, the kill window method can be invoked with the global shortcut Ctrl+Alt+Esc. The mouse cursor will then change into a deadly skull or some other pirate symbol. If you left-click on a window, the corresponding process will be killed - and unsaved data be lost. Typically, with right-click you can abort. ``` Message box text with KWin: ``` The kill window method can be invoked with a global shortcut which is currently set to: Ctrl+Alt+Esc The mouse cursor will then change into a deadly skull or some other pirate symbol. If you left-click on a window, the corresponding process will be killed - and unsaved data be lost. With right-click or the Esc key you can abort. ``` - Gregor --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review79097 --- On April 17, 2015, 7:32 a.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated April 17, 2015, 7:32 a.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 new message box https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/5565e806-bf16-4ef2-89f2-ac122bf3421c__messagebox.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On April 16, 2015, 3:14 p.m., Martin Gräßlin wrote: processui/ksysguardprocesslist.cpp, line 359 https://git.reviewboard.kde.org/r/122249/diff/9/?file=360668#file360668line359 You could know whether kwin is used - the window manager name is exported to the root window. Users might not know what KWin is. I also would like that better. I tried - QApplication::desktop()-window()-windowTitle(); - QApplication::desktop()-windowTitle(); Any other hint on how access this information? - Gregor --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review79059 --- On April 17, 2015, 7:32 a.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated April 17, 2015, 7:32 a.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 new message box https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/5565e806-bf16-4ef2-89f2-ac122bf3421c__messagebox.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On April 16, 2015, 3:14 p.m., Martin Gräßlin wrote: processui/ksysguardprocesslist.cpp, line 359 https://git.reviewboard.kde.org/r/122249/diff/9/?file=360668#file360668line359 You could know whether kwin is used - the window manager name is exported to the root window. Users might not know what KWin is. Gregor Mi wrote: I also would like that better. I tried - QApplication::desktop()-window()-windowTitle(); - QApplication::desktop()-windowTitle(); Any other hint on how access this information? Thomas Lübking wrote: http://api.kde.org/frameworks-api/frameworks5-apidocs/kwindowsystem/html/classNETRootInfo.html#ad6269ee8e82664340b1ac5dead86991f Ah, thanks. I found that NETRootInfo(QX11Info::connection(), NET::WMAllProperties).wmName() works. Though I had expected that NET::WMName instead of NET::WMAllProperties should also work, no? - Gregor --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review79059 --- On April 17, 2015, 7:32 a.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated April 17, 2015, 7:32 a.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 new message box https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/5565e806-bf16-4ef2-89f2-ac122bf3421c__messagebox.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated April 17, 2015, 8:33 a.m.) Review request for KDE Base Apps, Martin Gräßlin, John Tapsell, and Thomas Pfeiffer. Changes --- detect KWin and act accordingly 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 (updated) - 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 new message box https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/5565e806-bf16-4ef2-89f2-ac122bf3421c__messagebox.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On April 16, 2015, 3:14 nachm., Martin Gräßlin wrote: processui/ksysguardprocesslist.cpp, line 359 https://git.reviewboard.kde.org/r/122249/diff/9/?file=360668#file360668line359 You could know whether kwin is used - the window manager name is exported to the root window. Users might not know what KWin is. Gregor Mi wrote: I also would like that better. I tried - QApplication::desktop()-window()-windowTitle(); - QApplication::desktop()-windowTitle(); Any other hint on how access this information? Thomas Lübking wrote: http://api.kde.org/frameworks-api/frameworks5-apidocs/kwindowsystem/html/classNETRootInfo.html#ad6269ee8e82664340b1ac5dead86991f Gregor Mi wrote: Ah, thanks. I found that NETRootInfo(QX11Info::connection(), NET::WMAllProperties).wmName() works. Though I had expected that NET::WMName instead of NET::WMAllProperties should also work, no? try NET::SupportingWMCheck|NET::WMName - not actually sure. Smells like a bug indeed. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review79059 --- On April 17, 2015, 7:32 vorm., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated April 17, 2015, 7:32 vorm.) 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 new message box https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/5565e806-bf16-4ef2-89f2-ac122bf3421c__messagebox.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On April 16, 2015, 3:14 nachm., Martin Gräßlin wrote: processui/ksysguardprocesslist.cpp, line 359 https://git.reviewboard.kde.org/r/122249/diff/9/?file=360668#file360668line359 You could know whether kwin is used - the window manager name is exported to the root window. Users might not know what KWin is. Gregor Mi wrote: I also would like that better. I tried - QApplication::desktop()-window()-windowTitle(); - QApplication::desktop()-windowTitle(); Any other hint on how access this information? http://api.kde.org/frameworks-api/frameworks5-apidocs/kwindowsystem/html/classNETRootInfo.html#ad6269ee8e82664340b1ac5dead86991f - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review79059 --- On April 17, 2015, 7:32 vorm., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated April 17, 2015, 7:32 vorm.) 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 new message box https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/5565e806-bf16-4ef2-89f2-ac122bf3421c__messagebox.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review79059 --- Approach looks good to me, just a few minor cleanup comments below. CMakeLists.txt (lines 22 - 33) https://git.reviewboard.kde.org/r/122249/#comment54028 do we still need all those? I only see GlobalAccel used as a new dependency or am I missing something? processui/ksysguardprocesslist.cpp (line 344) https://git.reviewboard.kde.org/r/122249/#comment54024 please add a context for translators. I think a generic no set is quite difficult to translate. processui/ksysguardprocesslist.cpp (lines 353 - 361) https://git.reviewboard.kde.org/r/122249/#comment54025 not sure about the deadly skull and whether that's generically true. The cursor name is pirate. processui/ksysguardprocesslist.cpp (line 359) https://git.reviewboard.kde.org/r/122249/#comment54026 You could know whether kwin is used - the window manager name is exported to the root window. Users might not know what KWin is. processui/ksysguardprocesslist.cpp (line 1521) https://git.reviewboard.kde.org/r/122249/#comment54027 nitpick: added empty line - Martin Gräßlin On April 10, 2015, 1:23 p.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated April 10, 2015, 1:23 p.m.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. 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 - processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 CMakeLists.txt 66899e577a03786d894423a8f1ce5b3aeed6de8a processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 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 new message box https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/5565e806-bf16-4ef2-89f2-ac122bf3421c__messagebox.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On March 2, 2015, 7:47 a.m., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
Gregor Mi wrote:
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
Martin Gräßlin wrote:
I think you need to register killWindowAction with KGlobalAccel in some
way so that it loads the configured shortcut.
Gregor Mi wrote:
I found out how to prepare the QAction without KActionCollection.
auto killWindowAction = new QAction(nullptr);
killWindowAction-setProperty(componentName, kwin); // see impl of
KActionCollection
killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
// killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() killWindowAction-objectName(); // -- Kill Window
// qDebug() ac.actions().count(); // -- 1
qDebug() KGlobalAccel::self()-isComponentActive(kwin); // -- true
qDebug() KGlobalAccel::self()-allActionsForComponent({ kwin
}).count(); // (deprecated) -- 152
qDebug() KGlobalAccel::self()-hasShortcut(killWindowAction); // --
false
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count(); //
-- 0
qDebug()
KGlobalAccel::self()-defaultShortcut(killWindowAction).count(); // -- 0
delete killWindowAction;
Open issues:
1. Is it necessary to specify the shortcut context (default) somewhere?
2. How to tell KGlobalAccel to load the shortcuts for the given action.
Gregor Mi wrote:
Issue 1.: *not* necessary, see
kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
Martin Gräßlin wrote:
concerning 2: see
http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
shortcut context is (I think) not needed.
Gregor Mi wrote:
I read the API documentation about setShortcut and frankly I do not fully
understand it. It seems counter-intuitive to me to call that method in order
to *load* the shortcut.
Martin Gräßlin wrote:
yes the API is weird. But it's really like it: if one doesn't pass
NoAutloading the shortcut gets loaded.
Gregor Mi wrote:
yes, you are right, it is really working like this:
KActionCollection ac(nullptr, kwin);
auto killWindowAction = ac.addAction(Kill Window);
//killWindowAction-setProperty(componentName, kwin); // see impl
of KActionCollection
//killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
qDebug() killWindowAction-objectName(); // -- Kill Window
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review77589 --- processui/keyboardshortcututil.cpp https://git.reviewboard.kde.org/r/122249/#comment53290 requires https://git.reviewboard.kde.org/r/122981/ to be submitted - Gregor Mi On March 13, 2015, 10:08 p.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated March 13, 2015, 10:08 p.m.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. 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 5352e70f6f37daae76c1b3e2c1c9f149d235e3cd processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 processui/keyboardshortcututil.h PRE-CREATION processui/keyboardshortcututil.cpp PRE-CREATION processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546 tests/keyboardshortcututiltest.h PRE-CREATION tests/keyboardshortcututiltest.cpp PRE-CREATION 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 Drop down shows Kill Window https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/58df12c5-7350-4bb0-b602-c5716caa9836__screenshot_default2.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On März 2, 2015, 7:47 vorm., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
Gregor Mi wrote:
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
Martin Gräßlin wrote:
I think you need to register killWindowAction with KGlobalAccel in some
way so that it loads the configured shortcut.
Gregor Mi wrote:
I found out how to prepare the QAction without KActionCollection.
auto killWindowAction = new QAction(nullptr);
killWindowAction-setProperty(componentName, kwin); // see impl of
KActionCollection
killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
// killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() killWindowAction-objectName(); // -- Kill Window
// qDebug() ac.actions().count(); // -- 1
qDebug() KGlobalAccel::self()-isComponentActive(kwin); // -- true
qDebug() KGlobalAccel::self()-allActionsForComponent({ kwin
}).count(); // (deprecated) -- 152
qDebug() KGlobalAccel::self()-hasShortcut(killWindowAction); // --
false
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count(); //
-- 0
qDebug()
KGlobalAccel::self()-defaultShortcut(killWindowAction).count(); // -- 0
delete killWindowAction;
Open issues:
1. Is it necessary to specify the shortcut context (default) somewhere?
2. How to tell KGlobalAccel to load the shortcuts for the given action.
Gregor Mi wrote:
Issue 1.: *not* necessary, see
kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
Martin Gräßlin wrote:
concerning 2: see
http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
shortcut context is (I think) not needed.
Gregor Mi wrote:
I read the API documentation about setShortcut and frankly I do not fully
understand it. It seems counter-intuitive to me to call that method in order
to *load* the shortcut.
Martin Gräßlin wrote:
yes the API is weird. But it's really like it: if one doesn't pass
NoAutloading the shortcut gets loaded.
Gregor Mi wrote:
yes, you are right, it is really working like this:
KActionCollection ac(nullptr, kwin);
auto killWindowAction = ac.addAction(Kill Window);
//killWindowAction-setProperty(componentName, kwin); // see impl
of KActionCollection
//killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
qDebug() killWindowAction-objectName(); // -- Kill Window
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On March 2, 2015, 8:47 a.m., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
Gregor Mi wrote:
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
Martin Gräßlin wrote:
I think you need to register killWindowAction with KGlobalAccel in some
way so that it loads the configured shortcut.
Gregor Mi wrote:
I found out how to prepare the QAction without KActionCollection.
auto killWindowAction = new QAction(nullptr);
killWindowAction-setProperty(componentName, kwin); // see impl of
KActionCollection
killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
// killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() killWindowAction-objectName(); // -- Kill Window
// qDebug() ac.actions().count(); // -- 1
qDebug() KGlobalAccel::self()-isComponentActive(kwin); // -- true
qDebug() KGlobalAccel::self()-allActionsForComponent({ kwin
}).count(); // (deprecated) -- 152
qDebug() KGlobalAccel::self()-hasShortcut(killWindowAction); // --
false
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count(); //
-- 0
qDebug()
KGlobalAccel::self()-defaultShortcut(killWindowAction).count(); // -- 0
delete killWindowAction;
Open issues:
1. Is it necessary to specify the shortcut context (default) somewhere?
2. How to tell KGlobalAccel to load the shortcuts for the given action.
Gregor Mi wrote:
Issue 1.: *not* necessary, see
kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
Martin Gräßlin wrote:
concerning 2: see
http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
shortcut context is (I think) not needed.
Gregor Mi wrote:
I read the API documentation about setShortcut and frankly I do not fully
understand it. It seems counter-intuitive to me to call that method in order
to *load* the shortcut.
Martin Gräßlin wrote:
yes the API is weird. But it's really like it: if one doesn't pass
NoAutloading the shortcut gets loaded.
Gregor Mi wrote:
yes, you are right, it is really working like this:
KActionCollection ac(nullptr, kwin);
auto killWindowAction = ac.addAction(Kill Window);
//killWindowAction-setProperty(componentName, kwin); // see impl
of KActionCollection
//killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
qDebug() killWindowAction-objectName(); // -- Kill Window
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On März 2, 2015, 7:47 vorm., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
Gregor Mi wrote:
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
Martin Gräßlin wrote:
I think you need to register killWindowAction with KGlobalAccel in some
way so that it loads the configured shortcut.
Gregor Mi wrote:
I found out how to prepare the QAction without KActionCollection.
auto killWindowAction = new QAction(nullptr);
killWindowAction-setProperty(componentName, kwin); // see impl of
KActionCollection
killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
// killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() killWindowAction-objectName(); // -- Kill Window
// qDebug() ac.actions().count(); // -- 1
qDebug() KGlobalAccel::self()-isComponentActive(kwin); // -- true
qDebug() KGlobalAccel::self()-allActionsForComponent({ kwin
}).count(); // (deprecated) -- 152
qDebug() KGlobalAccel::self()-hasShortcut(killWindowAction); // --
false
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count(); //
-- 0
qDebug()
KGlobalAccel::self()-defaultShortcut(killWindowAction).count(); // -- 0
delete killWindowAction;
Open issues:
1. Is it necessary to specify the shortcut context (default) somewhere?
2. How to tell KGlobalAccel to load the shortcuts for the given action.
Gregor Mi wrote:
Issue 1.: *not* necessary, see
kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
Martin Gräßlin wrote:
concerning 2: see
http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
shortcut context is (I think) not needed.
Gregor Mi wrote:
I read the API documentation about setShortcut and frankly I do not fully
understand it. It seems counter-intuitive to me to call that method in order
to *load* the shortcut.
Martin Gräßlin wrote:
yes the API is weird. But it's really like it: if one doesn't pass
NoAutloading the shortcut gets loaded.
Gregor Mi wrote:
yes, you are right, it is really working like this:
KActionCollection ac(nullptr, kwin);
auto killWindowAction = ac.addAction(Kill Window);
//killWindowAction-setProperty(componentName, kwin); // see impl
of KActionCollection
//killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
qDebug() killWindowAction-objectName(); // -- Kill Window
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated March 13, 2015, 7:27 p.m.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. Changes --- Simplify the KeyboardShortcutUtil::findGlobalShortcutByComponentAndActionName method by using KGlobalAccel API. Unfortunately, at least on my machine, this simplified code disables the shortcut. Pressing the displayed shortcut has no effect until Plasma session relogin. 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. RR: Add a drop down menu to the End Process... button with one action: i18n(Kill a specific window... (Global shortcut: %1), killWindowShortcut) Diffs (updated) - tests/keyboardshortcututiltest.cpp PRE-CREATION tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546 processui/keyboardshortcututil.cpp PRE-CREATION processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 tests/keyboardshortcututiltest.h PRE-CREATION processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c processui/keyboardshortcututil.h PRE-CREATION processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 CMakeLists.txt 5352e70f6f37daae76c1b3e2c1c9f149d235e3cd 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 Drop down shows Kill Window https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/58df12c5-7350-4bb0-b602-c5716caa9836__screenshot_default2.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated March 13, 2015, 7:29 p.m.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. Repository: libksysguard Description (updated) --- 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 - tests/keyboardshortcututiltest.cpp PRE-CREATION tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546 processui/keyboardshortcututil.cpp PRE-CREATION processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 tests/keyboardshortcututiltest.h PRE-CREATION processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c processui/keyboardshortcututil.h PRE-CREATION processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 CMakeLists.txt 5352e70f6f37daae76c1b3e2c1c9f149d235e3cd 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 Drop down shows Kill Window https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/58df12c5-7350-4bb0-b602-c5716caa9836__screenshot_default2.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On March 2, 2015, 7:47 a.m., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
Gregor Mi wrote:
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
Martin Gräßlin wrote:
I think you need to register killWindowAction with KGlobalAccel in some
way so that it loads the configured shortcut.
Gregor Mi wrote:
I found out how to prepare the QAction without KActionCollection.
auto killWindowAction = new QAction(nullptr);
killWindowAction-setProperty(componentName, kwin); // see impl of
KActionCollection
killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
// killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() killWindowAction-objectName(); // -- Kill Window
// qDebug() ac.actions().count(); // -- 1
qDebug() KGlobalAccel::self()-isComponentActive(kwin); // -- true
qDebug() KGlobalAccel::self()-allActionsForComponent({ kwin
}).count(); // (deprecated) -- 152
qDebug() KGlobalAccel::self()-hasShortcut(killWindowAction); // --
false
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count(); //
-- 0
qDebug()
KGlobalAccel::self()-defaultShortcut(killWindowAction).count(); // -- 0
delete killWindowAction;
Open issues:
1. Is it necessary to specify the shortcut context (default) somewhere?
2. How to tell KGlobalAccel to load the shortcuts for the given action.
Gregor Mi wrote:
Issue 1.: *not* necessary, see
kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
Martin Gräßlin wrote:
concerning 2: see
http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
shortcut context is (I think) not needed.
Gregor Mi wrote:
I read the API documentation about setShortcut and frankly I do not fully
understand it. It seems counter-intuitive to me to call that method in order
to *load* the shortcut.
Martin Gräßlin wrote:
yes the API is weird. But it's really like it: if one doesn't pass
NoAutloading the shortcut gets loaded.
Gregor Mi wrote:
yes, you are right, it is really working like this:
KActionCollection ac(nullptr, kwin);
auto killWindowAction = ac.addAction(Kill Window);
//killWindowAction-setProperty(componentName, kwin); // see impl
of KActionCollection
//killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
qDebug() killWindowAction-objectName(); // -- Kill Window
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On März 2, 2015, 7:47 vorm., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
Gregor Mi wrote:
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
Martin Gräßlin wrote:
I think you need to register killWindowAction with KGlobalAccel in some
way so that it loads the configured shortcut.
Gregor Mi wrote:
I found out how to prepare the QAction without KActionCollection.
auto killWindowAction = new QAction(nullptr);
killWindowAction-setProperty(componentName, kwin); // see impl of
KActionCollection
killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
// killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() killWindowAction-objectName(); // -- Kill Window
// qDebug() ac.actions().count(); // -- 1
qDebug() KGlobalAccel::self()-isComponentActive(kwin); // -- true
qDebug() KGlobalAccel::self()-allActionsForComponent({ kwin
}).count(); // (deprecated) -- 152
qDebug() KGlobalAccel::self()-hasShortcut(killWindowAction); // --
false
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count(); //
-- 0
qDebug()
KGlobalAccel::self()-defaultShortcut(killWindowAction).count(); // -- 0
delete killWindowAction;
Open issues:
1. Is it necessary to specify the shortcut context (default) somewhere?
2. How to tell KGlobalAccel to load the shortcuts for the given action.
Gregor Mi wrote:
Issue 1.: *not* necessary, see
kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
Martin Gräßlin wrote:
concerning 2: see
http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
shortcut context is (I think) not needed.
Gregor Mi wrote:
I read the API documentation about setShortcut and frankly I do not fully
understand it. It seems counter-intuitive to me to call that method in order
to *load* the shortcut.
Martin Gräßlin wrote:
yes the API is weird. But it's really like it: if one doesn't pass
NoAutloading the shortcut gets loaded.
Gregor Mi wrote:
yes, you are right, it is really working like this:
KActionCollection ac(nullptr, kwin);
auto killWindowAction = ac.addAction(Kill Window);
//killWindowAction-setProperty(componentName, kwin); // see impl
of KActionCollection
//killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
qDebug() killWindowAction-objectName(); // -- Kill Window
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On March 2, 2015, 7:47 a.m., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
Gregor Mi wrote:
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
Martin Gräßlin wrote:
I think you need to register killWindowAction with KGlobalAccel in some
way so that it loads the configured shortcut.
Gregor Mi wrote:
I found out how to prepare the QAction without KActionCollection.
auto killWindowAction = new QAction(nullptr);
killWindowAction-setProperty(componentName, kwin); // see impl of
KActionCollection
killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
// killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() killWindowAction-objectName(); // -- Kill Window
// qDebug() ac.actions().count(); // -- 1
qDebug() KGlobalAccel::self()-isComponentActive(kwin); // -- true
qDebug() KGlobalAccel::self()-allActionsForComponent({ kwin
}).count(); // (deprecated) -- 152
qDebug() KGlobalAccel::self()-hasShortcut(killWindowAction); // --
false
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count(); //
-- 0
qDebug()
KGlobalAccel::self()-defaultShortcut(killWindowAction).count(); // -- 0
delete killWindowAction;
Open issues:
1. Is it necessary to specify the shortcut context (default) somewhere?
2. How to tell KGlobalAccel to load the shortcuts for the given action.
Gregor Mi wrote:
Issue 1.: *not* necessary, see
kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
Martin Gräßlin wrote:
concerning 2: see
http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
shortcut context is (I think) not needed.
Gregor Mi wrote:
I read the API documentation about setShortcut and frankly I do not fully
understand it. It seems counter-intuitive to me to call that method in order
to *load* the shortcut.
Martin Gräßlin wrote:
yes the API is weird. But it's really like it: if one doesn't pass
NoAutloading the shortcut gets loaded.
Gregor Mi wrote:
yes, you are right, it is really working like this:
KActionCollection ac(nullptr, kwin);
auto killWindowAction = ac.addAction(Kill Window);
//killWindowAction-setProperty(componentName, kwin); // see impl
of KActionCollection
//killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
qDebug() killWindowAction-objectName(); // -- Kill Window
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On March 2, 2015, 7:47 a.m., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
Gregor Mi wrote:
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
Martin Gräßlin wrote:
I think you need to register killWindowAction with KGlobalAccel in some
way so that it loads the configured shortcut.
Gregor Mi wrote:
I found out how to prepare the QAction without KActionCollection.
auto killWindowAction = new QAction(nullptr);
killWindowAction-setProperty(componentName, kwin); // see impl of
KActionCollection
killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
// killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() killWindowAction-objectName(); // -- Kill Window
// qDebug() ac.actions().count(); // -- 1
qDebug() KGlobalAccel::self()-isComponentActive(kwin); // -- true
qDebug() KGlobalAccel::self()-allActionsForComponent({ kwin
}).count(); // (deprecated) -- 152
qDebug() KGlobalAccel::self()-hasShortcut(killWindowAction); // --
false
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count(); //
-- 0
qDebug()
KGlobalAccel::self()-defaultShortcut(killWindowAction).count(); // -- 0
delete killWindowAction;
Open issues:
1. Is it necessary to specify the shortcut context (default) somewhere?
2. How to tell KGlobalAccel to load the shortcuts for the given action.
Gregor Mi wrote:
Issue 1.: *not* necessary, see
kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
Martin Gräßlin wrote:
concerning 2: see
http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
shortcut context is (I think) not needed.
Gregor Mi wrote:
I read the API documentation about setShortcut and frankly I do not fully
understand it. It seems counter-intuitive to me to call that method in order
to *load* the shortcut.
Martin Gräßlin wrote:
yes the API is weird. But it's really like it: if one doesn't pass
NoAutloading the shortcut gets loaded.
Gregor Mi wrote:
yes, you are right, it is really working like this:
KActionCollection ac(nullptr, kwin);
auto killWindowAction = ac.addAction(Kill Window);
//killWindowAction-setProperty(componentName, kwin); // see impl
of KActionCollection
//killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
qDebug() killWindowAction-objectName(); // -- Kill Window
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On March 2, 2015, 7:47 a.m., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
Gregor Mi wrote:
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
Martin Gräßlin wrote:
I think you need to register killWindowAction with KGlobalAccel in some
way so that it loads the configured shortcut.
Gregor Mi wrote:
I found out how to prepare the QAction without KActionCollection.
auto killWindowAction = new QAction(nullptr);
killWindowAction-setProperty(componentName, kwin); // see impl of
KActionCollection
killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
// killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() killWindowAction-objectName(); // -- Kill Window
// qDebug() ac.actions().count(); // -- 1
qDebug() KGlobalAccel::self()-isComponentActive(kwin); // -- true
qDebug() KGlobalAccel::self()-allActionsForComponent({ kwin
}).count(); // (deprecated) -- 152
qDebug() KGlobalAccel::self()-hasShortcut(killWindowAction); // --
false
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count(); //
-- 0
qDebug()
KGlobalAccel::self()-defaultShortcut(killWindowAction).count(); // -- 0
delete killWindowAction;
Open issues:
1. Is it necessary to specify the shortcut context (default) somewhere?
2. How to tell KGlobalAccel to load the shortcuts for the given action.
Gregor Mi wrote:
Issue 1.: *not* necessary, see
kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
Martin Gräßlin wrote:
concerning 2: see
http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
shortcut context is (I think) not needed.
Gregor Mi wrote:
I read the API documentation about setShortcut and frankly I do not fully
understand it. It seems counter-intuitive to me to call that method in order
to *load* the shortcut.
Martin Gräßlin wrote:
yes the API is weird. But it's really like it: if one doesn't pass
NoAutloading the shortcut gets loaded.
Gregor Mi wrote:
yes, you are right, it is really working like this:
KActionCollection ac(nullptr, kwin);
auto killWindowAction = ac.addAction(Kill Window);
//killWindowAction-setProperty(componentName, kwin); // see impl
of KActionCollection
//killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
qDebug() killWindowAction-objectName(); // -- Kill Window
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On März 2, 2015, 7:47 vorm., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
Gregor Mi wrote:
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
Martin Gräßlin wrote:
I think you need to register killWindowAction with KGlobalAccel in some
way so that it loads the configured shortcut.
Gregor Mi wrote:
I found out how to prepare the QAction without KActionCollection.
auto killWindowAction = new QAction(nullptr);
killWindowAction-setProperty(componentName, kwin); // see impl of
KActionCollection
killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
// killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() killWindowAction-objectName(); // -- Kill Window
// qDebug() ac.actions().count(); // -- 1
qDebug() KGlobalAccel::self()-isComponentActive(kwin); // -- true
qDebug() KGlobalAccel::self()-allActionsForComponent({ kwin
}).count(); // (deprecated) -- 152
qDebug() KGlobalAccel::self()-hasShortcut(killWindowAction); // --
false
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count(); //
-- 0
qDebug()
KGlobalAccel::self()-defaultShortcut(killWindowAction).count(); // -- 0
delete killWindowAction;
Open issues:
1. Is it necessary to specify the shortcut context (default) somewhere?
2. How to tell KGlobalAccel to load the shortcuts for the given action.
Gregor Mi wrote:
Issue 1.: *not* necessary, see
kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
Martin Gräßlin wrote:
concerning 2: see
http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
shortcut context is (I think) not needed.
Gregor Mi wrote:
I read the API documentation about setShortcut and frankly I do not fully
understand it. It seems counter-intuitive to me to call that method in order
to *load* the shortcut.
Martin Gräßlin wrote:
yes the API is weird. But it's really like it: if one doesn't pass
NoAutloading the shortcut gets loaded.
Gregor Mi wrote:
yes, you are right, it is really working like this:
KActionCollection ac(nullptr, kwin);
auto killWindowAction = ac.addAction(Kill Window);
//killWindowAction-setProperty(componentName, kwin); // see impl
of KActionCollection
//killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
qDebug() killWindowAction-objectName(); // -- Kill Window
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On March 2, 2015, 7:47 a.m., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
Gregor Mi wrote:
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
Martin Gräßlin wrote:
I think you need to register killWindowAction with KGlobalAccel in some
way so that it loads the configured shortcut.
Gregor Mi wrote:
I found out how to prepare the QAction without KActionCollection.
auto killWindowAction = new QAction(nullptr);
killWindowAction-setProperty(componentName, kwin); // see impl of
KActionCollection
killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
// killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() killWindowAction-objectName(); // -- Kill Window
// qDebug() ac.actions().count(); // -- 1
qDebug() KGlobalAccel::self()-isComponentActive(kwin); // -- true
qDebug() KGlobalAccel::self()-allActionsForComponent({ kwin
}).count(); // (deprecated) -- 152
qDebug() KGlobalAccel::self()-hasShortcut(killWindowAction); // --
false
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count(); //
-- 0
qDebug()
KGlobalAccel::self()-defaultShortcut(killWindowAction).count(); // -- 0
delete killWindowAction;
Open issues:
1. Is it necessary to specify the shortcut context (default) somewhere?
2. How to tell KGlobalAccel to load the shortcuts for the given action.
Gregor Mi wrote:
Issue 1.: *not* necessary, see
kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
Martin Gräßlin wrote:
concerning 2: see
http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
shortcut context is (I think) not needed.
Gregor Mi wrote:
I read the API documentation about setShortcut and frankly I do not fully
understand it. It seems counter-intuitive to me to call that method in order
to *load* the shortcut.
Martin Gräßlin wrote:
yes the API is weird. But it's really like it: if one doesn't pass
NoAutloading the shortcut gets loaded.
Gregor Mi wrote:
yes, you are right, it is really working like this:
KActionCollection ac(nullptr, kwin);
auto killWindowAction = ac.addAction(Kill Window);
//killWindowAction-setProperty(componentName, kwin); // see impl
of KActionCollection
//killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
qDebug() killWindowAction-objectName(); // -- Kill Window
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated March 13, 2015, 10:08 p.m.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. Changes --- Fix the global shortcut gets unset issue by using a new method: KGlobalAccel::loadShortcutFromGlobalSettings 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 (updated) - CMakeLists.txt 5352e70f6f37daae76c1b3e2c1c9f149d235e3cd processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 processui/keyboardshortcututil.h PRE-CREATION processui/keyboardshortcututil.cpp PRE-CREATION processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546 tests/keyboardshortcututiltest.h PRE-CREATION tests/keyboardshortcututiltest.cpp PRE-CREATION 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 Drop down shows Kill Window https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/58df12c5-7350-4bb0-b602-c5716caa9836__screenshot_default2.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On March 2, 2015, 7:47 a.m., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
Gregor Mi wrote:
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
Martin Gräßlin wrote:
I think you need to register killWindowAction with KGlobalAccel in some
way so that it loads the configured shortcut.
Gregor Mi wrote:
I found out how to prepare the QAction without KActionCollection.
auto killWindowAction = new QAction(nullptr);
killWindowAction-setProperty(componentName, kwin); // see impl of
KActionCollection
killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
// killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() killWindowAction-objectName(); // -- Kill Window
// qDebug() ac.actions().count(); // -- 1
qDebug() KGlobalAccel::self()-isComponentActive(kwin); // -- true
qDebug() KGlobalAccel::self()-allActionsForComponent({ kwin
}).count(); // (deprecated) -- 152
qDebug() KGlobalAccel::self()-hasShortcut(killWindowAction); // --
false
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count(); //
-- 0
qDebug()
KGlobalAccel::self()-defaultShortcut(killWindowAction).count(); // -- 0
delete killWindowAction;
Open issues:
1. Is it necessary to specify the shortcut context (default) somewhere?
2. How to tell KGlobalAccel to load the shortcuts for the given action.
Gregor Mi wrote:
Issue 1.: *not* necessary, see
kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
Martin Gräßlin wrote:
concerning 2: see
http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
shortcut context is (I think) not needed.
Gregor Mi wrote:
I read the API documentation about setShortcut and frankly I do not fully
understand it. It seems counter-intuitive to me to call that method in order
to *load* the shortcut.
Martin Gräßlin wrote:
yes the API is weird. But it's really like it: if one doesn't pass
NoAutloading the shortcut gets loaded.
Gregor Mi wrote:
yes, you are right, it is really working like this:
KActionCollection ac(nullptr, kwin);
auto killWindowAction = ac.addAction(Kill Window);
//killWindowAction-setProperty(componentName, kwin); // see impl
of KActionCollection
//killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
qDebug() killWindowAction-objectName(); // -- Kill Window
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On March 2, 2015, 7:47 a.m., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
Gregor Mi wrote:
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
Martin Gräßlin wrote:
I think you need to register killWindowAction with KGlobalAccel in some
way so that it loads the configured shortcut.
Gregor Mi wrote:
I found out how to prepare the QAction without KActionCollection.
auto killWindowAction = new QAction(nullptr);
killWindowAction-setProperty(componentName, kwin); // see impl of
KActionCollection
killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
// killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() killWindowAction-objectName(); // -- Kill Window
// qDebug() ac.actions().count(); // -- 1
qDebug() KGlobalAccel::self()-isComponentActive(kwin); // -- true
qDebug() KGlobalAccel::self()-allActionsForComponent({ kwin
}).count(); // (deprecated) -- 152
qDebug() KGlobalAccel::self()-hasShortcut(killWindowAction); // --
false
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count(); //
-- 0
qDebug()
KGlobalAccel::self()-defaultShortcut(killWindowAction).count(); // -- 0
delete killWindowAction;
Open issues:
1. Is it necessary to specify the shortcut context (default) somewhere?
2. How to tell KGlobalAccel to load the shortcuts for the given action.
Gregor Mi wrote:
Issue 1.: *not* necessary, see
kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
Martin Gräßlin wrote:
concerning 2: see
http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
shortcut context is (I think) not needed.
Gregor Mi wrote:
I read the API documentation about setShortcut and frankly I do not fully
understand it. It seems counter-intuitive to me to call that method in order
to *load* the shortcut.
Martin Gräßlin wrote:
yes the API is weird. But it's really like it: if one doesn't pass
NoAutloading the shortcut gets loaded.
Gregor Mi wrote:
yes, you are right, it is really working like this:
KActionCollection ac(nullptr, kwin);
auto killWindowAction = ac.addAction(Kill Window);
//killWindowAction-setProperty(componentName, kwin); // see impl
of KActionCollection
//killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
qDebug() killWindowAction-objectName(); // -- Kill Window
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On March 2, 2015, 7:47 a.m., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
Gregor Mi wrote:
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
Martin Gräßlin wrote:
I think you need to register killWindowAction with KGlobalAccel in some
way so that it loads the configured shortcut.
Gregor Mi wrote:
I found out how to prepare the QAction without KActionCollection.
auto killWindowAction = new QAction(nullptr);
killWindowAction-setProperty(componentName, kwin); // see impl of
KActionCollection
killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
// killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() killWindowAction-objectName(); // -- Kill Window
// qDebug() ac.actions().count(); // -- 1
qDebug() KGlobalAccel::self()-isComponentActive(kwin); // -- true
qDebug() KGlobalAccel::self()-allActionsForComponent({ kwin
}).count(); // (deprecated) -- 152
qDebug() KGlobalAccel::self()-hasShortcut(killWindowAction); // --
false
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count(); //
-- 0
qDebug()
KGlobalAccel::self()-defaultShortcut(killWindowAction).count(); // -- 0
delete killWindowAction;
Open issues:
1. Is it necessary to specify the shortcut context (default) somewhere?
2. How to tell KGlobalAccel to load the shortcuts for the given action.
Gregor Mi wrote:
Issue 1.: *not* necessary, see
kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
Martin Gräßlin wrote:
concerning 2: see
http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
shortcut context is (I think) not needed.
Gregor Mi wrote:
I read the API documentation about setShortcut and frankly I do not fully
understand it. It seems counter-intuitive to me to call that method in order
to *load* the shortcut.
Martin Gräßlin wrote:
yes the API is weird. But it's really like it: if one doesn't pass
NoAutloading the shortcut gets loaded.
Gregor Mi wrote:
yes, you are right, it is really working like this:
KActionCollection ac(nullptr, kwin);
auto killWindowAction = ac.addAction(Kill Window);
//killWindowAction-setProperty(componentName, kwin); // see impl
of KActionCollection
//killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
qDebug() killWindowAction-objectName(); // -- Kill Window
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On March 2, 2015, 8:47 a.m., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
Gregor Mi wrote:
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
I think you need to register killWindowAction with KGlobalAccel in some way so
that it loads the configured shortcut.
- Martin
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/#review76861
---
On Feb. 27, 2015, 2:18 a.m., Gregor Mi wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/
---
(Updated Feb. 27, 2015, 2:18 a.m.)
Review request for KDE Base Apps, Martin Gräßlin and John Tapsell.
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.
RR:
Add a drop down menu to the End Process... button with one action:
i18n(Kill a specific window... (Global shortcut: %1), killWindowShortcut)
Diffs
-
processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6
processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3
processui/keyboardshortcututil.h PRE-CREATION
processui/keyboardshortcututil.cpp PRE-CREATION
processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c
tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546
tests/keyboardshortcututiltest.h PRE-CREATION
tests/keyboardshortcututiltest.cpp PRE-CREATION
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
Drop down shows Kill Window
https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/58df12c5-7350-4bb0-b602-c5716caa9836__screenshot_default2.png
Thanks,
Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On March 2, 2015, 7:47 a.m., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
- Gregor
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/#review76861
---
On Feb. 27, 2015, 1:18 a.m., Gregor Mi wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/
---
(Updated Feb. 27, 2015, 1:18 a.m.)
Review request for KDE Base Apps, Martin Gräßlin and John Tapsell.
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.
RR:
Add a drop down menu to the End Process... button with one action:
i18n(Kill a specific window... (Global shortcut: %1), killWindowShortcut)
Diffs
-
processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6
processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3
processui/keyboardshortcututil.h PRE-CREATION
processui/keyboardshortcututil.cpp PRE-CREATION
processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c
tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546
tests/keyboardshortcututiltest.h PRE-CREATION
tests/keyboardshortcututiltest.cpp PRE-CREATION
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
Drop down shows Kill Window
https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/58df12c5-7350-4bb0-b602-c5716caa9836__screenshot_default2.png
Thanks,
Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On March 2, 2015, 7:47 a.m., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
Gregor Mi wrote:
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
Martin Gräßlin wrote:
I think you need to register killWindowAction with KGlobalAccel in some
way so that it loads the configured shortcut.
I found out how to prepare the QAction without KActionCollection.
auto killWindowAction = new QAction(nullptr);
killWindowAction-setProperty(componentName, kwin); // see impl of
KActionCollection
killWindowAction-setObjectName(Kill Window); // see impl of KActionCollection
// killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() killWindowAction-objectName(); // -- Kill Window
// qDebug() ac.actions().count(); // -- 1
qDebug() KGlobalAccel::self()-isComponentActive(kwin); // -- true
qDebug() KGlobalAccel::self()-allActionsForComponent({ kwin }).count();
// (deprecated) -- 152
qDebug() KGlobalAccel::self()-hasShortcut(killWindowAction); // -- false
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count(); // -- 0
qDebug() KGlobalAccel::self()-defaultShortcut(killWindowAction).count(); //
-- 0
delete killWindowAction;
Open issues:
1. Is it necessary to specify the shortcut context (default) somewhere?
2. How to tell KGlobalAccel to load the shortcuts for the given action.
- Gregor
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/#review76861
---
On Feb. 27, 2015, 1:18 a.m., Gregor Mi wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/
---
(Updated Feb. 27, 2015, 1:18 a.m.)
Review request for KDE Base Apps, Martin Gräßlin and John Tapsell.
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.
RR:
Add a drop down menu to the End Process... button with one action:
i18n(Kill a specific window... (Global shortcut: %1), killWindowShortcut)
Diffs
-
processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6
processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3
processui/keyboardshortcututil.h PRE-CREATION
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On March 2, 2015, 7:47 a.m., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
Gregor Mi wrote:
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
Martin Gräßlin wrote:
I think you need to register killWindowAction with KGlobalAccel in some
way so that it loads the configured shortcut.
Gregor Mi wrote:
I found out how to prepare the QAction without KActionCollection.
auto killWindowAction = new QAction(nullptr);
killWindowAction-setProperty(componentName, kwin); // see impl of
KActionCollection
killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
// killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() killWindowAction-objectName(); // -- Kill Window
// qDebug() ac.actions().count(); // -- 1
qDebug() KGlobalAccel::self()-isComponentActive(kwin); // -- true
qDebug() KGlobalAccel::self()-allActionsForComponent({ kwin
}).count(); // (deprecated) -- 152
qDebug() KGlobalAccel::self()-hasShortcut(killWindowAction); // --
false
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count(); //
-- 0
qDebug()
KGlobalAccel::self()-defaultShortcut(killWindowAction).count(); // -- 0
delete killWindowAction;
Open issues:
1. Is it necessary to specify the shortcut context (default) somewhere?
2. How to tell KGlobalAccel to load the shortcuts for the given action.
Issue 1.: *not* necessary, see
kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
- Gregor
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/#review76861
---
On Feb. 27, 2015, 1:18 a.m., Gregor Mi wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/
---
(Updated Feb. 27, 2015, 1:18 a.m.)
Review request for KDE Base Apps, Martin Gräßlin and John Tapsell.
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.
RR:
Add a drop down menu to the End Process... button with one action:
i18n(Kill a specific window... (Global shortcut: %1), killWindowShortcut)
Diffs
-
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On March 2, 2015, 8:47 a.m., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
Gregor Mi wrote:
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
Martin Gräßlin wrote:
I think you need to register killWindowAction with KGlobalAccel in some
way so that it loads the configured shortcut.
Gregor Mi wrote:
I found out how to prepare the QAction without KActionCollection.
auto killWindowAction = new QAction(nullptr);
killWindowAction-setProperty(componentName, kwin); // see impl of
KActionCollection
killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
// killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() killWindowAction-objectName(); // -- Kill Window
// qDebug() ac.actions().count(); // -- 1
qDebug() KGlobalAccel::self()-isComponentActive(kwin); // -- true
qDebug() KGlobalAccel::self()-allActionsForComponent({ kwin
}).count(); // (deprecated) -- 152
qDebug() KGlobalAccel::self()-hasShortcut(killWindowAction); // --
false
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count(); //
-- 0
qDebug()
KGlobalAccel::self()-defaultShortcut(killWindowAction).count(); // -- 0
delete killWindowAction;
Open issues:
1. Is it necessary to specify the shortcut context (default) somewhere?
2. How to tell KGlobalAccel to load the shortcuts for the given action.
Gregor Mi wrote:
Issue 1.: *not* necessary, see
kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
concerning 2: see
http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
shortcut context is (I think) not needed.
- Martin
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/#review76861
---
On Feb. 27, 2015, 2:18 a.m., Gregor Mi wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/
---
(Updated Feb. 27, 2015, 2:18 a.m.)
Review request for KDE Base Apps, Martin Gräßlin and John Tapsell.
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
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On March 2, 2015, 8:47 a.m., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
Gregor Mi wrote:
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
Martin Gräßlin wrote:
I think you need to register killWindowAction with KGlobalAccel in some
way so that it loads the configured shortcut.
Gregor Mi wrote:
I found out how to prepare the QAction without KActionCollection.
auto killWindowAction = new QAction(nullptr);
killWindowAction-setProperty(componentName, kwin); // see impl of
KActionCollection
killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
// killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() killWindowAction-objectName(); // -- Kill Window
// qDebug() ac.actions().count(); // -- 1
qDebug() KGlobalAccel::self()-isComponentActive(kwin); // -- true
qDebug() KGlobalAccel::self()-allActionsForComponent({ kwin
}).count(); // (deprecated) -- 152
qDebug() KGlobalAccel::self()-hasShortcut(killWindowAction); // --
false
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count(); //
-- 0
qDebug()
KGlobalAccel::self()-defaultShortcut(killWindowAction).count(); // -- 0
delete killWindowAction;
Open issues:
1. Is it necessary to specify the shortcut context (default) somewhere?
2. How to tell KGlobalAccel to load the shortcuts for the given action.
Gregor Mi wrote:
Issue 1.: *not* necessary, see
kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
Martin Gräßlin wrote:
concerning 2: see
http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
shortcut context is (I think) not needed.
Gregor Mi wrote:
I read the API documentation about setShortcut and frankly I do not fully
understand it. It seems counter-intuitive to me to call that method in order
to *load* the shortcut.
yes the API is weird. But it's really like it: if one doesn't pass NoAutloading
the shortcut gets loaded.
- Martin
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/#review76861
---
On Feb. 27, 2015, 2:18 a.m., Gregor Mi wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On March 2, 2015, 7:47 a.m., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
Gregor Mi wrote:
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
Martin Gräßlin wrote:
I think you need to register killWindowAction with KGlobalAccel in some
way so that it loads the configured shortcut.
Gregor Mi wrote:
I found out how to prepare the QAction without KActionCollection.
auto killWindowAction = new QAction(nullptr);
killWindowAction-setProperty(componentName, kwin); // see impl of
KActionCollection
killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
// killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() killWindowAction-objectName(); // -- Kill Window
// qDebug() ac.actions().count(); // -- 1
qDebug() KGlobalAccel::self()-isComponentActive(kwin); // -- true
qDebug() KGlobalAccel::self()-allActionsForComponent({ kwin
}).count(); // (deprecated) -- 152
qDebug() KGlobalAccel::self()-hasShortcut(killWindowAction); // --
false
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count(); //
-- 0
qDebug()
KGlobalAccel::self()-defaultShortcut(killWindowAction).count(); // -- 0
delete killWindowAction;
Open issues:
1. Is it necessary to specify the shortcut context (default) somewhere?
2. How to tell KGlobalAccel to load the shortcuts for the given action.
Gregor Mi wrote:
Issue 1.: *not* necessary, see
kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
Martin Gräßlin wrote:
concerning 2: see
http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
shortcut context is (I think) not needed.
Gregor Mi wrote:
I read the API documentation about setShortcut and frankly I do not fully
understand it. It seems counter-intuitive to me to call that method in order
to *load* the shortcut.
Martin Gräßlin wrote:
yes the API is weird. But it's really like it: if one doesn't pass
NoAutloading the shortcut gets loaded.
yes, you are right, it is really working like this:
KActionCollection ac(nullptr, kwin);
auto killWindowAction = ac.addAction(Kill Window);
//killWindowAction-setProperty(componentName, kwin); // see impl of
KActionCollection
//killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
qDebug() killWindowAction-objectName(); // -- Kill Window
qDebug() KGlobalAccel::self()-hasShortcut(killWindowAction);
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On March 2, 2015, 7:47 a.m., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
Martin Gräßlin wrote:
try: ac.addAction instead of ac.action
For reference code look at e.g.
kwin/effects/desktopgrid/desktopgrid_config.cpp
Gregor Mi wrote:
I tried this:
KActionCollection ac(nullptr, kwin);
ac.setConfigGroup(default); // needed?
ac.setConfigGlobal(true);
auto killWindowAction = ac.addAction(Kill Window);
killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() ac.actions().count();
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count();
/*
CONSOLE OUTPUT:
1
0
*/
Martin Gräßlin wrote:
I think you need to register killWindowAction with KGlobalAccel in some
way so that it loads the configured shortcut.
Gregor Mi wrote:
I found out how to prepare the QAction without KActionCollection.
auto killWindowAction = new QAction(nullptr);
killWindowAction-setProperty(componentName, kwin); // see impl of
KActionCollection
killWindowAction-setObjectName(Kill Window); // see impl of
KActionCollection
// killWindowAction-setProperty(isConfigurationAction, true); // neded?
qDebug() killWindowAction-objectName(); // -- Kill Window
// qDebug() ac.actions().count(); // -- 1
qDebug() KGlobalAccel::self()-isComponentActive(kwin); // -- true
qDebug() KGlobalAccel::self()-allActionsForComponent({ kwin
}).count(); // (deprecated) -- 152
qDebug() KGlobalAccel::self()-hasShortcut(killWindowAction); // --
false
qDebug() KGlobalAccel::self()-shortcut(killWindowAction).count(); //
-- 0
qDebug()
KGlobalAccel::self()-defaultShortcut(killWindowAction).count(); // -- 0
delete killWindowAction;
Open issues:
1. Is it necessary to specify the shortcut context (default) somewhere?
2. How to tell KGlobalAccel to load the shortcuts for the given action.
Gregor Mi wrote:
Issue 1.: *not* necessary, see
kde/workspace/plasma-workspace/kglobalaccel/component.h, line 98
Martin Gräßlin wrote:
concerning 2: see
http://api.kde.org/frameworks-api/frameworks5-apidocs/kglobalaccel/html/classKGlobalAccel.html#a66ce504227e7e563f24de4c6b26b0395
shortcut context is (I think) not needed.
I read the API documentation about setShortcut and frankly I do not fully
understand it. It seems counter-intuitive to me to call that method in order to
*load* the shortcut.
- Gregor
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/#review76861
---
On Feb. 27, 2015, 1:18 a.m., Gregor Mi wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/
---
(Updated Feb. 27, 2015, 1:18 a.m.)
Review request for KDE Base Apps, Martin Gräßlin and
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On March 2, 2015, 8:47 a.m., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
Thomas Lübking wrote:
You'd have qApp, but I don't actually think so.
try: ac.addAction instead of ac.action
For reference code look at e.g. kwin/effects/desktopgrid/desktopgrid_config.cpp
- Martin
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/#review76861
---
On Feb. 27, 2015, 2:18 a.m., Gregor Mi wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/
---
(Updated Feb. 27, 2015, 2:18 a.m.)
Review request for KDE Base Apps, Martin Gräßlin and John Tapsell.
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.
RR:
Add a drop down menu to the End Process... button with one action:
i18n(Kill a specific window... (Global shortcut: %1), killWindowShortcut)
Diffs
-
processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6
processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3
processui/keyboardshortcututil.h PRE-CREATION
processui/keyboardshortcututil.cpp PRE-CREATION
processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c
tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546
tests/keyboardshortcututiltest.h PRE-CREATION
tests/keyboardshortcututiltest.cpp PRE-CREATION
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
Drop down shows Kill Window
https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/58df12c5-7350-4bb0-b602-c5716caa9836__screenshot_default2.png
Thanks,
Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On März 2, 2015, 7:47 vorm., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
Gregor Mi wrote:
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
You'd have qApp, but I don't actually think so.
- Thomas
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/#review76861
---
On Feb. 27, 2015, 1:18 vorm., Gregor Mi wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/
---
(Updated Feb. 27, 2015, 1:18 vorm.)
Review request for KDE Base Apps, Martin Gräßlin and John Tapsell.
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.
RR:
Add a drop down menu to the End Process... button with one action:
i18n(Kill a specific window... (Global shortcut: %1), killWindowShortcut)
Diffs
-
processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6
processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3
processui/keyboardshortcututil.h PRE-CREATION
processui/keyboardshortcututil.cpp PRE-CREATION
processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c
tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546
tests/keyboardshortcututiltest.h PRE-CREATION
tests/keyboardshortcututiltest.cpp PRE-CREATION
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
Drop down shows Kill Window
https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/58df12c5-7350-4bb0-b602-c5716caa9836__screenshot_default2.png
Thanks,
Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On March 2, 2015, 7:47 a.m., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
Thomas Lübking wrote:
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
I have no QObject* as parent. Can this be the cause?
KActionCollection ac(nullptr, kwin);
ac.setConfigGlobal(true);
auto killWindowAction = ac.action(Kill Window);
qDebug() ac.actions().count();
qDebug() killWindowAction;
/*
RESULT:
0
QObject(0x0)
*/
- Gregor
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/#review76861
---
On Feb. 27, 2015, 1:18 a.m., Gregor Mi wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/
---
(Updated Feb. 27, 2015, 1:18 a.m.)
Review request for KDE Base Apps, Martin Gräßlin and John Tapsell.
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.
RR:
Add a drop down menu to the End Process... button with one action:
i18n(Kill a specific window... (Global shortcut: %1), killWindowShortcut)
Diffs
-
processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6
processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3
processui/keyboardshortcututil.h PRE-CREATION
processui/keyboardshortcututil.cpp PRE-CREATION
processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c
tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546
tests/keyboardshortcututiltest.h PRE-CREATION
tests/keyboardshortcututiltest.cpp PRE-CREATION
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
Drop down shows Kill Window
https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/58df12c5-7350-4bb0-b602-c5716caa9836__screenshot_default2.png
Thanks,
Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On March 2, 2015, 7:47 a.m., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Thanks for the hint but I am not sure of how to use the API in such a way. I
tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions = kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
- Gregor
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/#review76861
---
On Feb. 27, 2015, 1:18 a.m., Gregor Mi wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/
---
(Updated Feb. 27, 2015, 1:18 a.m.)
Review request for KDE Base Apps, Martin Gräßlin and John Tapsell.
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.
RR:
Add a drop down menu to the End Process... button with one action:
i18n(Kill a specific window... (Global shortcut: %1), killWindowShortcut)
Diffs
-
processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6
processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3
processui/keyboardshortcututil.h PRE-CREATION
processui/keyboardshortcututil.cpp PRE-CREATION
processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c
tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546
tests/keyboardshortcututiltest.h PRE-CREATION
tests/keyboardshortcututiltest.cpp PRE-CREATION
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
Drop down shows Kill Window
https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/58df12c5-7350-4bb0-b602-c5716caa9836__screenshot_default2.png
Thanks,
Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On März 2, 2015, 7:47 vorm., Martin Gräßlin wrote:
processui/keyboardshortcututil.cpp, line 46
https://git.reviewboard.kde.org/r/122249/diff/6/?file=351945#file351945line46
This looks to complicated. It should be much easier to do with the
KGlobalAccel API:
* create a KActionCollection for component kwin
* add a QAction with the shortcut name you want
* ask KGlobalAccel to load the shortcut for it.
Gregor Mi wrote:
Thanks for the hint but I am not sure of how to use the API in such a
way. I tried two things:
1)
org::kde::KGlobalAccel kglobalaccel(org.kde.kglobalaccel,
/kglobalaccel, bus);
auto kwinActions =
kglobalaccel.allActionsForComponent(QStringList(kwin));
Q_FOREACH(auto aaa, kwinActions.value()) {
//qDebug() aaa; // (kwin, Kill Window, KWin, Kill
Window)
}
Then I wonder how to feed the QStringList to a KActionCollection.
2)
KActionCollection ac(nullptr, QString());
ac.setComponentName(kwin);
// ac.importGlobalShortcuts();
Q_FOREACH(auto bbb, ac.actions()) {
if (bbb-text() == Kill Window) {
qDebug() bbb;
}
}
But the ac.actions() list is empty.
Which of the two ways should be used?
tried this?
---
KActionCollection ac(this, kwin);
ac.setConfigGlobal(true);
QAction *act = ac.action(Kill Window);
- Thomas
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/#review76861
---
On Feb. 27, 2015, 1:18 vorm., Gregor Mi wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122249/
---
(Updated Feb. 27, 2015, 1:18 vorm.)
Review request for KDE Base Apps, Martin Gräßlin and John Tapsell.
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.
RR:
Add a drop down menu to the End Process... button with one action:
i18n(Kill a specific window... (Global shortcut: %1), killWindowShortcut)
Diffs
-
processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6
processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3
processui/keyboardshortcututil.h PRE-CREATION
processui/keyboardshortcututil.cpp PRE-CREATION
processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c
tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546
tests/keyboardshortcututiltest.h PRE-CREATION
tests/keyboardshortcututiltest.cpp PRE-CREATION
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
Drop down shows Kill Window
https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/58df12c5-7350-4bb0-b602-c5716caa9836__screenshot_default2.png
Thanks,
Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated Feb. 27, 2015, 1:18 a.m.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. Changes --- Fix message box. What about having this message box as intermediate solution until the xkill generalization is done? 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. RR: Add a drop down menu to the End Process... button with one action: i18n(Kill a specific window... (Global shortcut: %1), killWindowShortcut) Diffs (updated) - processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 processui/keyboardshortcututil.h PRE-CREATION processui/keyboardshortcututil.cpp PRE-CREATION processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546 tests/keyboardshortcututiltest.h PRE-CREATION tests/keyboardshortcututiltest.cpp PRE-CREATION 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 Drop down shows Kill Window https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/58df12c5-7350-4bb0-b602-c5716caa9836__screenshot_default2.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On Jan. 26, 2015, 7:05 vorm., Martin Gräßlin wrote:
My opinion is that this is a feature which should not be exposed in
libksysguard. It actually ties libksysguard to KWin, while libksysguard was
in the past also used in e.g. kdevelop.
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself.
Martin Gräßlin wrote:
In addition: KWin's global shortcut action names are not public API. We
do not guarantee that we don't change them, we do not guarantee that they are
exposed at all (KWin handling shortcuts internally without kglobalaccel on
Wayland?). I do not want to run into situations that we cannot change our
code because external usage makes it impossible.
Thomas Lübking wrote:
In case there was larger demand for invoking such action (taskbar,
dedicated plasmoid, ...) one could move the xkill functionality into
KWindowSystem (option for portage) - invoking a kwin shortcut through a
kglobalaccel dbus call is a hack. Maybe sufficient for any downstream
solution, but easily broken feature.
Gregor Mi wrote:
First of all, a clarification of this RR's intentions:
1) The original End Process... tooltip says you can always use
Ctrl+Alt+Esc... which is wrong as soon as someone changes the keyboard
shortcut exposed by KWin. So this should be fixed.
2) Make the Kill Window feature more discoverable. It is a seldom used
feature which makes it harder to remember.
About invoking Kill Window:
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself. [Martin]
...one could move the xkill functionality into KWindowSystem...
[Thomas]
Without knowing the amount of xkill code I suspect that having a dbus
call that loosly couples libksysguard to KWin is probably easier to maintain
than 2 times the xkill code.
Having said that, what about moving the xkill code to a common location
as Thomas suggested?
We do not guarantee that we don't change them, we do not guarantee that
they are exposed at all ... I do not want to run into situations that we
cannot change our code because external usage makes it impossible.
Understood. But would it then be possible at all to get the current
shortcut to display it to the user?
Martin Gräßlin wrote:
Ok, so this addresses two issues using one solution: exposing KWin's
internal shortcut. This is bad as outlined above.
I agree that 1) needs fixing. This can be done in the way as approached
in this review request: check whether kwin is registered on kglobalaccel and
get the key command. If it's done that way the fault is with libksysguard in
case KWin changes the shortcut name or doesn't use kglobalaccel any more.
Another fix is of course to just hide the shortcut.
2) is a different issue. Whether it's needed to expose the functionality
in addition from libksysguard is probably questionable. A better approach to
do this would be through a method in KWindowSystem. This does not need to
duplicate the code, it could also just send a client message to the window
manager to start the kill window process. Through KWindowSystem we can check
whether the feature is supported by the window manager and could exclude if
not supported. But and that's a big but: the feature would not be able to
work if it's triggered from a (context) menu or drop down list (it needs to
grab mouse). Given that I'm hesistant to say that it should be added to
kwindowsystem at all.
Thomas Lübking wrote:
ad 2)
I'd have said to rather *move* the code to KWindowSystem and use it from
there by any client (incl. kwin)
This allows porting the solution (in case such is possible on other
systems at all) as well as to invoke the feature unconditionally (ie. instead
of is this kwin? yes? tell kwin to trigger xkill. just trigger the xkill
functionality)
About the popupmenu:
The issue is global, ie. as long as a popup (or other grabber) is
around, the kwin shortcut neither works.
It's kind of the client codes problem to deal w/ a false return (eg.
invoke a timer and/or timered retries)
Gregor Mi wrote:
ad 1) (shortcut)
I could live with adapting (or remove) the shortcut retrieval as soon as
it will not be possible anymore. As long as it is, I would show it. (I
suspect as long as the shortcut is not hard-coded there will be a some way to
get it)
ad 2) (invoke window kill)
I looked a Kwin's source code. For reference, here are the two methods I
found to kill a window:
```
/*!
Kill Window feature, similar to xkill
*/
void Workspace::slotKillWindow()
{
if (m_windowKiller.isNull()) {
m_windowKiller.reset(new KillWindow());
}
m_windowKiller-start();
}
and
/**
* Kills
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On Jan. 26, 2015, 8:05 a.m., Martin Gräßlin wrote:
My opinion is that this is a feature which should not be exposed in
libksysguard. It actually ties libksysguard to KWin, while libksysguard was
in the past also used in e.g. kdevelop.
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself.
Martin Gräßlin wrote:
In addition: KWin's global shortcut action names are not public API. We
do not guarantee that we don't change them, we do not guarantee that they are
exposed at all (KWin handling shortcuts internally without kglobalaccel on
Wayland?). I do not want to run into situations that we cannot change our
code because external usage makes it impossible.
Thomas Lübking wrote:
In case there was larger demand for invoking such action (taskbar,
dedicated plasmoid, ...) one could move the xkill functionality into
KWindowSystem (option for portage) - invoking a kwin shortcut through a
kglobalaccel dbus call is a hack. Maybe sufficient for any downstream
solution, but easily broken feature.
Gregor Mi wrote:
First of all, a clarification of this RR's intentions:
1) The original End Process... tooltip says you can always use
Ctrl+Alt+Esc... which is wrong as soon as someone changes the keyboard
shortcut exposed by KWin. So this should be fixed.
2) Make the Kill Window feature more discoverable. It is a seldom used
feature which makes it harder to remember.
About invoking Kill Window:
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself. [Martin]
...one could move the xkill functionality into KWindowSystem...
[Thomas]
Without knowing the amount of xkill code I suspect that having a dbus
call that loosly couples libksysguard to KWin is probably easier to maintain
than 2 times the xkill code.
Having said that, what about moving the xkill code to a common location
as Thomas suggested?
We do not guarantee that we don't change them, we do not guarantee that
they are exposed at all ... I do not want to run into situations that we
cannot change our code because external usage makes it impossible.
Understood. But would it then be possible at all to get the current
shortcut to display it to the user?
Martin Gräßlin wrote:
Ok, so this addresses two issues using one solution: exposing KWin's
internal shortcut. This is bad as outlined above.
I agree that 1) needs fixing. This can be done in the way as approached
in this review request: check whether kwin is registered on kglobalaccel and
get the key command. If it's done that way the fault is with libksysguard in
case KWin changes the shortcut name or doesn't use kglobalaccel any more.
Another fix is of course to just hide the shortcut.
2) is a different issue. Whether it's needed to expose the functionality
in addition from libksysguard is probably questionable. A better approach to
do this would be through a method in KWindowSystem. This does not need to
duplicate the code, it could also just send a client message to the window
manager to start the kill window process. Through KWindowSystem we can check
whether the feature is supported by the window manager and could exclude if
not supported. But and that's a big but: the feature would not be able to
work if it's triggered from a (context) menu or drop down list (it needs to
grab mouse). Given that I'm hesistant to say that it should be added to
kwindowsystem at all.
Thomas Lübking wrote:
ad 2)
I'd have said to rather *move* the code to KWindowSystem and use it from
there by any client (incl. kwin)
This allows porting the solution (in case such is possible on other
systems at all) as well as to invoke the feature unconditionally (ie. instead
of is this kwin? yes? tell kwin to trigger xkill. just trigger the xkill
functionality)
About the popupmenu:
The issue is global, ie. as long as a popup (or other grabber) is
around, the kwin shortcut neither works.
It's kind of the client codes problem to deal w/ a false return (eg.
invoke a timer and/or timered retries)
Gregor Mi wrote:
ad 1) (shortcut)
I could live with adapting (or remove) the shortcut retrieval as soon as
it will not be possible anymore. As long as it is, I would show it. (I
suspect as long as the shortcut is not hard-coded there will be a some way to
get it)
ad 2) (invoke window kill)
I looked a Kwin's source code. For reference, here are the two methods I
found to kill a window:
```
/*!
Kill Window feature, similar to xkill
*/
void Workspace::slotKillWindow()
{
if (m_windowKiller.isNull()) {
m_windowKiller.reset(new KillWindow());
}
m_windowKiller-start();
}
and
/**
* Kills
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated Feb. 23, 2015, 9:15 p.m.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. Changes --- Replace invoking the kill method by just showing a message box that shows the global shortcut and a message what to expect. 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. RR: Add a drop down menu to the End Process... button with one action: i18n(Kill a specific window... (Global shortcut: %1), killWindowShortcut) Diffs (updated) - processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 processui/keyboardshortcututil.h PRE-CREATION processui/keyboardshortcututil.cpp PRE-CREATION processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546 tests/keyboardshortcututiltest.h PRE-CREATION tests/keyboardshortcututiltest.cpp PRE-CREATION 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 Drop down shows Kill Window https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/58df12c5-7350-4bb0-b602-c5716caa9836__screenshot_default2.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review76499 --- After update to latest master I got a crash (in master) of ksysguard when I click the End Process... button. The confirmation dialog is about to appear but then seg fault. export KDE_DEBUG=1 139]gregor@catgroove[KF5 set]:~/dev/kf5/src ksysguard ksysguard(3891)/kf5.kiconthemes KIconLoaderPrivate::initIconThemes: Theme tree: (Breeze) ksysguard(3891)/default KLocalizedStringPrivate::toString: Trying to convert empty KLocalizedString to QString. // click the End Process... buton ksysguard(3891)/kf5.kservice.sycoca KSycocaPrivate::openDatabase: Trying to open ksycoca from /home/gregor/.cache5/ksycoca5 ksysguard(3891)/default KNotificationManager::notify: Calling notify on Sound Segmentation fault I also wonder why I don't get a stack trace on console even though I build in debug configuration. Any hint? - Gregor Mi On Feb. 20, 2015, 11:35 p.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated Feb. 20, 2015, 11:35 p.m.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. 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. RR: Add a drop down menu to the End Process... button with one action: i18n(Kill a specific window... (Global shortcut: %1), killWindowShortcut) Diffs - processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 processui/keyboardshortcututil.h PRE-CREATION processui/keyboardshortcututil.cpp PRE-CREATION processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546 tests/keyboardshortcututiltest.h PRE-CREATION tests/keyboardshortcututiltest.cpp PRE-CREATION 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 Drop down shows Kill Window https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/58df12c5-7350-4bb0-b602-c5716caa9836__screenshot_default2.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On Jan. 26, 2015, 8:05 a.m., Martin Gräßlin wrote:
My opinion is that this is a feature which should not be exposed in
libksysguard. It actually ties libksysguard to KWin, while libksysguard was
in the past also used in e.g. kdevelop.
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself.
Martin Gräßlin wrote:
In addition: KWin's global shortcut action names are not public API. We
do not guarantee that we don't change them, we do not guarantee that they are
exposed at all (KWin handling shortcuts internally without kglobalaccel on
Wayland?). I do not want to run into situations that we cannot change our
code because external usage makes it impossible.
Thomas Lübking wrote:
In case there was larger demand for invoking such action (taskbar,
dedicated plasmoid, ...) one could move the xkill functionality into
KWindowSystem (option for portage) - invoking a kwin shortcut through a
kglobalaccel dbus call is a hack. Maybe sufficient for any downstream
solution, but easily broken feature.
Gregor Mi wrote:
First of all, a clarification of this RR's intentions:
1) The original End Process... tooltip says you can always use
Ctrl+Alt+Esc... which is wrong as soon as someone changes the keyboard
shortcut exposed by KWin. So this should be fixed.
2) Make the Kill Window feature more discoverable. It is a seldom used
feature which makes it harder to remember.
About invoking Kill Window:
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself. [Martin]
...one could move the xkill functionality into KWindowSystem...
[Thomas]
Without knowing the amount of xkill code I suspect that having a dbus
call that loosly couples libksysguard to KWin is probably easier to maintain
than 2 times the xkill code.
Having said that, what about moving the xkill code to a common location
as Thomas suggested?
We do not guarantee that we don't change them, we do not guarantee that
they are exposed at all ... I do not want to run into situations that we
cannot change our code because external usage makes it impossible.
Understood. But would it then be possible at all to get the current
shortcut to display it to the user?
Martin Gräßlin wrote:
Ok, so this addresses two issues using one solution: exposing KWin's
internal shortcut. This is bad as outlined above.
I agree that 1) needs fixing. This can be done in the way as approached
in this review request: check whether kwin is registered on kglobalaccel and
get the key command. If it's done that way the fault is with libksysguard in
case KWin changes the shortcut name or doesn't use kglobalaccel any more.
Another fix is of course to just hide the shortcut.
2) is a different issue. Whether it's needed to expose the functionality
in addition from libksysguard is probably questionable. A better approach to
do this would be through a method in KWindowSystem. This does not need to
duplicate the code, it could also just send a client message to the window
manager to start the kill window process. Through KWindowSystem we can check
whether the feature is supported by the window manager and could exclude if
not supported. But and that's a big but: the feature would not be able to
work if it's triggered from a (context) menu or drop down list (it needs to
grab mouse). Given that I'm hesistant to say that it should be added to
kwindowsystem at all.
Thomas Lübking wrote:
ad 2)
I'd have said to rather *move* the code to KWindowSystem and use it from
there by any client (incl. kwin)
This allows porting the solution (in case such is possible on other
systems at all) as well as to invoke the feature unconditionally (ie. instead
of is this kwin? yes? tell kwin to trigger xkill. just trigger the xkill
functionality)
About the popupmenu:
The issue is global, ie. as long as a popup (or other grabber) is
around, the kwin shortcut neither works.
It's kind of the client codes problem to deal w/ a false return (eg.
invoke a timer and/or timered retries)
Gregor Mi wrote:
ad 1) (shortcut)
I could live with adapting (or remove) the shortcut retrieval as soon as
it will not be possible anymore. As long as it is, I would show it. (I
suspect as long as the shortcut is not hard-coded there will be a some way to
get it)
ad 2) (invoke window kill)
I looked a Kwin's source code. For reference, here are the two methods I
found to kill a window:
```
/*!
Kill Window feature, similar to xkill
*/
void Workspace::slotKillWindow()
{
if (m_windowKiller.isNull()) {
m_windowKiller.reset(new KillWindow());
}
m_windowKiller-start();
}
and
/**
* Kills
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On Jan. 26, 2015, 7:05 vorm., Martin Gräßlin wrote:
My opinion is that this is a feature which should not be exposed in
libksysguard. It actually ties libksysguard to KWin, while libksysguard was
in the past also used in e.g. kdevelop.
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself.
Martin Gräßlin wrote:
In addition: KWin's global shortcut action names are not public API. We
do not guarantee that we don't change them, we do not guarantee that they are
exposed at all (KWin handling shortcuts internally without kglobalaccel on
Wayland?). I do not want to run into situations that we cannot change our
code because external usage makes it impossible.
Thomas Lübking wrote:
In case there was larger demand for invoking such action (taskbar,
dedicated plasmoid, ...) one could move the xkill functionality into
KWindowSystem (option for portage) - invoking a kwin shortcut through a
kglobalaccel dbus call is a hack. Maybe sufficient for any downstream
solution, but easily broken feature.
Gregor Mi wrote:
First of all, a clarification of this RR's intentions:
1) The original End Process... tooltip says you can always use
Ctrl+Alt+Esc... which is wrong as soon as someone changes the keyboard
shortcut exposed by KWin. So this should be fixed.
2) Make the Kill Window feature more discoverable. It is a seldom used
feature which makes it harder to remember.
About invoking Kill Window:
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself. [Martin]
...one could move the xkill functionality into KWindowSystem...
[Thomas]
Without knowing the amount of xkill code I suspect that having a dbus
call that loosly couples libksysguard to KWin is probably easier to maintain
than 2 times the xkill code.
Having said that, what about moving the xkill code to a common location
as Thomas suggested?
We do not guarantee that we don't change them, we do not guarantee that
they are exposed at all ... I do not want to run into situations that we
cannot change our code because external usage makes it impossible.
Understood. But would it then be possible at all to get the current
shortcut to display it to the user?
Martin Gräßlin wrote:
Ok, so this addresses two issues using one solution: exposing KWin's
internal shortcut. This is bad as outlined above.
I agree that 1) needs fixing. This can be done in the way as approached
in this review request: check whether kwin is registered on kglobalaccel and
get the key command. If it's done that way the fault is with libksysguard in
case KWin changes the shortcut name or doesn't use kglobalaccel any more.
Another fix is of course to just hide the shortcut.
2) is a different issue. Whether it's needed to expose the functionality
in addition from libksysguard is probably questionable. A better approach to
do this would be through a method in KWindowSystem. This does not need to
duplicate the code, it could also just send a client message to the window
manager to start the kill window process. Through KWindowSystem we can check
whether the feature is supported by the window manager and could exclude if
not supported. But and that's a big but: the feature would not be able to
work if it's triggered from a (context) menu or drop down list (it needs to
grab mouse). Given that I'm hesistant to say that it should be added to
kwindowsystem at all.
Thomas Lübking wrote:
ad 2)
I'd have said to rather *move* the code to KWindowSystem and use it from
there by any client (incl. kwin)
This allows porting the solution (in case such is possible on other
systems at all) as well as to invoke the feature unconditionally (ie. instead
of is this kwin? yes? tell kwin to trigger xkill. just trigger the xkill
functionality)
About the popupmenu:
The issue is global, ie. as long as a popup (or other grabber) is
around, the kwin shortcut neither works.
It's kind of the client codes problem to deal w/ a false return (eg.
invoke a timer and/or timered retries)
Gregor Mi wrote:
ad 1) (shortcut)
I could live with adapting (or remove) the shortcut retrieval as soon as
it will not be possible anymore. As long as it is, I would show it. (I
suspect as long as the shortcut is not hard-coded there will be a some way to
get it)
ad 2) (invoke window kill)
I looked a Kwin's source code. For reference, here are the two methods I
found to kill a window:
```
/*!
Kill Window feature, similar to xkill
*/
void Workspace::slotKillWindow()
{
if (m_windowKiller.isNull()) {
m_windowKiller.reset(new KillWindow());
}
m_windowKiller-start();
}
and
/**
* Kills
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated Feb. 20, 2015, 11:35 p.m.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. Changes --- - Use QProcess::startDetached(xkill); instead of using the KWin method. This is not as advanced as the KWin method (e.g. the action can only be aborted with right-click instead of also Esc) but this way there is no coupling to KWin - Add a Don't ask again message box that warns the user about what will happen. 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. RR: Add a drop down menu to the End Process... button with one action: i18n(Kill a specific window... (Global shortcut: %1), killWindowShortcut) Diffs (updated) - processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 processui/keyboardshortcututil.h PRE-CREATION processui/keyboardshortcututil.cpp PRE-CREATION processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546 tests/keyboardshortcututiltest.h PRE-CREATION tests/keyboardshortcututiltest.cpp PRE-CREATION 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 Drop down shows Kill Window https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/58df12c5-7350-4bb0-b602-c5716caa9836__screenshot_default2.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On Jan. 26, 2015, 7:05 vorm., Martin Gräßlin wrote:
My opinion is that this is a feature which should not be exposed in
libksysguard. It actually ties libksysguard to KWin, while libksysguard was
in the past also used in e.g. kdevelop.
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself.
Martin Gräßlin wrote:
In addition: KWin's global shortcut action names are not public API. We
do not guarantee that we don't change them, we do not guarantee that they are
exposed at all (KWin handling shortcuts internally without kglobalaccel on
Wayland?). I do not want to run into situations that we cannot change our
code because external usage makes it impossible.
Thomas Lübking wrote:
In case there was larger demand for invoking such action (taskbar,
dedicated plasmoid, ...) one could move the xkill functionality into
KWindowSystem (option for portage) - invoking a kwin shortcut through a
kglobalaccel dbus call is a hack. Maybe sufficient for any downstream
solution, but easily broken feature.
Gregor Mi wrote:
First of all, a clarification of this RR's intentions:
1) The original End Process... tooltip says you can always use
Ctrl+Alt+Esc... which is wrong as soon as someone changes the keyboard
shortcut exposed by KWin. So this should be fixed.
2) Make the Kill Window feature more discoverable. It is a seldom used
feature which makes it harder to remember.
About invoking Kill Window:
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself. [Martin]
...one could move the xkill functionality into KWindowSystem...
[Thomas]
Without knowing the amount of xkill code I suspect that having a dbus
call that loosly couples libksysguard to KWin is probably easier to maintain
than 2 times the xkill code.
Having said that, what about moving the xkill code to a common location
as Thomas suggested?
We do not guarantee that we don't change them, we do not guarantee that
they are exposed at all ... I do not want to run into situations that we
cannot change our code because external usage makes it impossible.
Understood. But would it then be possible at all to get the current
shortcut to display it to the user?
Martin Gräßlin wrote:
Ok, so this addresses two issues using one solution: exposing KWin's
internal shortcut. This is bad as outlined above.
I agree that 1) needs fixing. This can be done in the way as approached
in this review request: check whether kwin is registered on kglobalaccel and
get the key command. If it's done that way the fault is with libksysguard in
case KWin changes the shortcut name or doesn't use kglobalaccel any more.
Another fix is of course to just hide the shortcut.
2) is a different issue. Whether it's needed to expose the functionality
in addition from libksysguard is probably questionable. A better approach to
do this would be through a method in KWindowSystem. This does not need to
duplicate the code, it could also just send a client message to the window
manager to start the kill window process. Through KWindowSystem we can check
whether the feature is supported by the window manager and could exclude if
not supported. But and that's a big but: the feature would not be able to
work if it's triggered from a (context) menu or drop down list (it needs to
grab mouse). Given that I'm hesistant to say that it should be added to
kwindowsystem at all.
Thomas Lübking wrote:
ad 2)
I'd have said to rather *move* the code to KWindowSystem and use it from
there by any client (incl. kwin)
This allows porting the solution (in case such is possible on other
systems at all) as well as to invoke the feature unconditionally (ie. instead
of is this kwin? yes? tell kwin to trigger xkill. just trigger the xkill
functionality)
About the popupmenu:
The issue is global, ie. as long as a popup (or other grabber) is
around, the kwin shortcut neither works.
It's kind of the client codes problem to deal w/ a false return (eg.
invoke a timer and/or timered retries)
Gregor Mi wrote:
ad 1) (shortcut)
I could live with adapting (or remove) the shortcut retrieval as soon as
it will not be possible anymore. As long as it is, I would show it. (I
suspect as long as the shortcut is not hard-coded there will be a some way to
get it)
ad 2) (invoke window kill)
I looked a Kwin's source code. For reference, here are the two methods I
found to kill a window:
```
/*!
Kill Window feature, similar to xkill
*/
void Workspace::slotKillWindow()
{
if (m_windowKiller.isNull()) {
m_windowKiller.reset(new KillWindow());
}
m_windowKiller-start();
}
and
/**
* Kills
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review76389 --- processui/ksysguardprocesslist.cpp https://git.reviewboard.kde.org/r/122249/#comment52615 leaving aside that the patch is not clean (still contains kglobalaccel stuff, ie. is probably just a variant proposal): I don't have xkill installed. It's not a dependency of anything in KDE - you'd have to add it (for package maintainers, no idea how to do that, though) (ftr: the popup grabs mouse limitations mostly hold for invoking xkill as well - just that there it would become harder to check for successful invocation) - Thomas Lübking On Feb. 20, 2015, 11:35 nachm., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated Feb. 20, 2015, 11:35 nachm.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. 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. RR: Add a drop down menu to the End Process... button with one action: i18n(Kill a specific window... (Global shortcut: %1), killWindowShortcut) Diffs - processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 processui/keyboardshortcututil.h PRE-CREATION processui/keyboardshortcututil.cpp PRE-CREATION processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546 tests/keyboardshortcututiltest.h PRE-CREATION tests/keyboardshortcututiltest.cpp PRE-CREATION 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 Drop down shows Kill Window https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/58df12c5-7350-4bb0-b602-c5716caa9836__screenshot_default2.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On Jan. 26, 2015, 7:05 a.m., Martin Gräßlin wrote:
My opinion is that this is a feature which should not be exposed in
libksysguard. It actually ties libksysguard to KWin, while libksysguard was
in the past also used in e.g. kdevelop.
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself.
Martin Gräßlin wrote:
In addition: KWin's global shortcut action names are not public API. We
do not guarantee that we don't change them, we do not guarantee that they are
exposed at all (KWin handling shortcuts internally without kglobalaccel on
Wayland?). I do not want to run into situations that we cannot change our
code because external usage makes it impossible.
Thomas Lübking wrote:
In case there was larger demand for invoking such action (taskbar,
dedicated plasmoid, ...) one could move the xkill functionality into
KWindowSystem (option for portage) - invoking a kwin shortcut through a
kglobalaccel dbus call is a hack. Maybe sufficient for any downstream
solution, but easily broken feature.
Gregor Mi wrote:
First of all, a clarification of this RR's intentions:
1) The original End Process... tooltip says you can always use
Ctrl+Alt+Esc... which is wrong as soon as someone changes the keyboard
shortcut exposed by KWin. So this should be fixed.
2) Make the Kill Window feature more discoverable. It is a seldom used
feature which makes it harder to remember.
About invoking Kill Window:
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself. [Martin]
...one could move the xkill functionality into KWindowSystem...
[Thomas]
Without knowing the amount of xkill code I suspect that having a dbus
call that loosly couples libksysguard to KWin is probably easier to maintain
than 2 times the xkill code.
Having said that, what about moving the xkill code to a common location
as Thomas suggested?
We do not guarantee that we don't change them, we do not guarantee that
they are exposed at all ... I do not want to run into situations that we
cannot change our code because external usage makes it impossible.
Understood. But would it then be possible at all to get the current
shortcut to display it to the user?
Martin Gräßlin wrote:
Ok, so this addresses two issues using one solution: exposing KWin's
internal shortcut. This is bad as outlined above.
I agree that 1) needs fixing. This can be done in the way as approached
in this review request: check whether kwin is registered on kglobalaccel and
get the key command. If it's done that way the fault is with libksysguard in
case KWin changes the shortcut name or doesn't use kglobalaccel any more.
Another fix is of course to just hide the shortcut.
2) is a different issue. Whether it's needed to expose the functionality
in addition from libksysguard is probably questionable. A better approach to
do this would be through a method in KWindowSystem. This does not need to
duplicate the code, it could also just send a client message to the window
manager to start the kill window process. Through KWindowSystem we can check
whether the feature is supported by the window manager and could exclude if
not supported. But and that's a big but: the feature would not be able to
work if it's triggered from a (context) menu or drop down list (it needs to
grab mouse). Given that I'm hesistant to say that it should be added to
kwindowsystem at all.
Thomas Lübking wrote:
ad 2)
I'd have said to rather *move* the code to KWindowSystem and use it from
there by any client (incl. kwin)
This allows porting the solution (in case such is possible on other
systems at all) as well as to invoke the feature unconditionally (ie. instead
of is this kwin? yes? tell kwin to trigger xkill. just trigger the xkill
functionality)
About the popupmenu:
The issue is global, ie. as long as a popup (or other grabber) is
around, the kwin shortcut neither works.
It's kind of the client codes problem to deal w/ a false return (eg.
invoke a timer and/or timered retries)
Gregor Mi wrote:
ad 1) (shortcut)
I could live with adapting (or remove) the shortcut retrieval as soon as
it will not be possible anymore. As long as it is, I would show it. (I
suspect as long as the shortcut is not hard-coded there will be a some way to
get it)
ad 2) (invoke window kill)
I looked a Kwin's source code. For reference, here are the two methods I
found to kill a window:
```
/*!
Kill Window feature, similar to xkill
*/
void Workspace::slotKillWindow()
{
if (m_windowKiller.isNull()) {
m_windowKiller.reset(new KillWindow());
}
m_windowKiller-start();
}
and
/**
* Kills
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On Feb. 21, 2015, 4:08 p.m., Thomas Lübking wrote: processui/ksysguardprocesslist.cpp, line 367 https://git.reviewboard.kde.org/r/122249/diff/4/?file=350459#file350459line367 leaving aside that the patch is not clean (still contains kglobalaccel stuff, ie. is probably just a variant proposal): I don't have xkill installed. It's not a dependency of anything in KDE - you'd have to add it (for package maintainers, no idea how to do that, though) (ftr: the popup grabs mouse limitations mostly hold for invoking xkill as well - just that there it would become harder to check for successful invocation) kglobalaccel: I thought this would be ok to get the global shortcut for the killing action. xkill: ah, ok. I thought it comes with X. I'll remove it. popup grabs mouse limitation: I am not that familiar with that. How would that affect an xill invocation? - Gregor --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review76389 --- On Feb. 20, 2015, 11:35 p.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated Feb. 20, 2015, 11:35 p.m.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. 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. RR: Add a drop down menu to the End Process... button with one action: i18n(Kill a specific window... (Global shortcut: %1), killWindowShortcut) Diffs - processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 processui/keyboardshortcututil.h PRE-CREATION processui/keyboardshortcututil.cpp PRE-CREATION processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546 tests/keyboardshortcututiltest.h PRE-CREATION tests/keyboardshortcututiltest.cpp PRE-CREATION 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 Drop down shows Kill Window https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/58df12c5-7350-4bb0-b602-c5716caa9836__screenshot_default2.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On Jan. 26, 2015, 7:05 a.m., Martin Gräßlin wrote:
My opinion is that this is a feature which should not be exposed in
libksysguard. It actually ties libksysguard to KWin, while libksysguard was
in the past also used in e.g. kdevelop.
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself.
Martin Gräßlin wrote:
In addition: KWin's global shortcut action names are not public API. We
do not guarantee that we don't change them, we do not guarantee that they are
exposed at all (KWin handling shortcuts internally without kglobalaccel on
Wayland?). I do not want to run into situations that we cannot change our
code because external usage makes it impossible.
Thomas Lübking wrote:
In case there was larger demand for invoking such action (taskbar,
dedicated plasmoid, ...) one could move the xkill functionality into
KWindowSystem (option for portage) - invoking a kwin shortcut through a
kglobalaccel dbus call is a hack. Maybe sufficient for any downstream
solution, but easily broken feature.
Gregor Mi wrote:
First of all, a clarification of this RR's intentions:
1) The original End Process... tooltip says you can always use
Ctrl+Alt+Esc... which is wrong as soon as someone changes the keyboard
shortcut exposed by KWin. So this should be fixed.
2) Make the Kill Window feature more discoverable. It is a seldom used
feature which makes it harder to remember.
About invoking Kill Window:
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself. [Martin]
...one could move the xkill functionality into KWindowSystem...
[Thomas]
Without knowing the amount of xkill code I suspect that having a dbus
call that loosly couples libksysguard to KWin is probably easier to maintain
than 2 times the xkill code.
Having said that, what about moving the xkill code to a common location
as Thomas suggested?
We do not guarantee that we don't change them, we do not guarantee that
they are exposed at all ... I do not want to run into situations that we
cannot change our code because external usage makes it impossible.
Understood. But would it then be possible at all to get the current
shortcut to display it to the user?
Martin Gräßlin wrote:
Ok, so this addresses two issues using one solution: exposing KWin's
internal shortcut. This is bad as outlined above.
I agree that 1) needs fixing. This can be done in the way as approached
in this review request: check whether kwin is registered on kglobalaccel and
get the key command. If it's done that way the fault is with libksysguard in
case KWin changes the shortcut name or doesn't use kglobalaccel any more.
Another fix is of course to just hide the shortcut.
2) is a different issue. Whether it's needed to expose the functionality
in addition from libksysguard is probably questionable. A better approach to
do this would be through a method in KWindowSystem. This does not need to
duplicate the code, it could also just send a client message to the window
manager to start the kill window process. Through KWindowSystem we can check
whether the feature is supported by the window manager and could exclude if
not supported. But and that's a big but: the feature would not be able to
work if it's triggered from a (context) menu or drop down list (it needs to
grab mouse). Given that I'm hesistant to say that it should be added to
kwindowsystem at all.
Thomas Lübking wrote:
ad 2)
I'd have said to rather *move* the code to KWindowSystem and use it from
there by any client (incl. kwin)
This allows porting the solution (in case such is possible on other
systems at all) as well as to invoke the feature unconditionally (ie. instead
of is this kwin? yes? tell kwin to trigger xkill. just trigger the xkill
functionality)
About the popupmenu:
The issue is global, ie. as long as a popup (or other grabber) is
around, the kwin shortcut neither works.
It's kind of the client codes problem to deal w/ a false return (eg.
invoke a timer and/or timered retries)
Gregor Mi wrote:
ad 1) (shortcut)
I could live with adapting (or remove) the shortcut retrieval as soon as
it will not be possible anymore. As long as it is, I would show it. (I
suspect as long as the shortcut is not hard-coded there will be a some way to
get it)
ad 2) (invoke window kill)
I looked a Kwin's source code. For reference, here are the two methods I
found to kill a window:
```
/*!
Kill Window feature, similar to xkill
*/
void Workspace::slotKillWindow()
{
if (m_windowKiller.isNull()) {
m_windowKiller.reset(new KillWindow());
}
m_windowKiller-start();
}
and
/**
* Kills
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On Jan. 26, 2015, 8:05 a.m., Martin Gräßlin wrote:
My opinion is that this is a feature which should not be exposed in
libksysguard. It actually ties libksysguard to KWin, while libksysguard was
in the past also used in e.g. kdevelop.
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself.
Martin Gräßlin wrote:
In addition: KWin's global shortcut action names are not public API. We
do not guarantee that we don't change them, we do not guarantee that they are
exposed at all (KWin handling shortcuts internally without kglobalaccel on
Wayland?). I do not want to run into situations that we cannot change our
code because external usage makes it impossible.
Thomas Lübking wrote:
In case there was larger demand for invoking such action (taskbar,
dedicated plasmoid, ...) one could move the xkill functionality into
KWindowSystem (option for portage) - invoking a kwin shortcut through a
kglobalaccel dbus call is a hack. Maybe sufficient for any downstream
solution, but easily broken feature.
Gregor Mi wrote:
First of all, a clarification of this RR's intentions:
1) The original End Process... tooltip says you can always use
Ctrl+Alt+Esc... which is wrong as soon as someone changes the keyboard
shortcut exposed by KWin. So this should be fixed.
2) Make the Kill Window feature more discoverable. It is a seldom used
feature which makes it harder to remember.
About invoking Kill Window:
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself. [Martin]
...one could move the xkill functionality into KWindowSystem...
[Thomas]
Without knowing the amount of xkill code I suspect that having a dbus
call that loosly couples libksysguard to KWin is probably easier to maintain
than 2 times the xkill code.
Having said that, what about moving the xkill code to a common location
as Thomas suggested?
We do not guarantee that we don't change them, we do not guarantee that
they are exposed at all ... I do not want to run into situations that we
cannot change our code because external usage makes it impossible.
Understood. But would it then be possible at all to get the current
shortcut to display it to the user?
Martin Gräßlin wrote:
Ok, so this addresses two issues using one solution: exposing KWin's
internal shortcut. This is bad as outlined above.
I agree that 1) needs fixing. This can be done in the way as approached
in this review request: check whether kwin is registered on kglobalaccel and
get the key command. If it's done that way the fault is with libksysguard in
case KWin changes the shortcut name or doesn't use kglobalaccel any more.
Another fix is of course to just hide the shortcut.
2) is a different issue. Whether it's needed to expose the functionality
in addition from libksysguard is probably questionable. A better approach to
do this would be through a method in KWindowSystem. This does not need to
duplicate the code, it could also just send a client message to the window
manager to start the kill window process. Through KWindowSystem we can check
whether the feature is supported by the window manager and could exclude if
not supported. But and that's a big but: the feature would not be able to
work if it's triggered from a (context) menu or drop down list (it needs to
grab mouse). Given that I'm hesistant to say that it should be added to
kwindowsystem at all.
Thomas Lübking wrote:
ad 2)
I'd have said to rather *move* the code to KWindowSystem and use it from
there by any client (incl. kwin)
This allows porting the solution (in case such is possible on other
systems at all) as well as to invoke the feature unconditionally (ie. instead
of is this kwin? yes? tell kwin to trigger xkill. just trigger the xkill
functionality)
About the popupmenu:
The issue is global, ie. as long as a popup (or other grabber) is
around, the kwin shortcut neither works.
It's kind of the client codes problem to deal w/ a false return (eg.
invoke a timer and/or timered retries)
Gregor Mi wrote:
ad 1) (shortcut)
I could live with adapting (or remove) the shortcut retrieval as soon as
it will not be possible anymore. As long as it is, I would show it. (I
suspect as long as the shortcut is not hard-coded there will be a some way to
get it)
ad 2) (invoke window kill)
I looked a Kwin's source code. For reference, here are the two methods I
found to kill a window:
```
/*!
Kill Window feature, similar to xkill
*/
void Workspace::slotKillWindow()
{
if (m_windowKiller.isNull()) {
m_windowKiller.reset(new KillWindow());
}
m_windowKiller-start();
}
and
/**
* Kills
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On Jan. 26, 2015, 7:05 a.m., Martin Gräßlin wrote:
My opinion is that this is a feature which should not be exposed in
libksysguard. It actually ties libksysguard to KWin, while libksysguard was
in the past also used in e.g. kdevelop.
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself.
Martin Gräßlin wrote:
In addition: KWin's global shortcut action names are not public API. We
do not guarantee that we don't change them, we do not guarantee that they are
exposed at all (KWin handling shortcuts internally without kglobalaccel on
Wayland?). I do not want to run into situations that we cannot change our
code because external usage makes it impossible.
Thomas Lübking wrote:
In case there was larger demand for invoking such action (taskbar,
dedicated plasmoid, ...) one could move the xkill functionality into
KWindowSystem (option for portage) - invoking a kwin shortcut through a
kglobalaccel dbus call is a hack. Maybe sufficient for any downstream
solution, but easily broken feature.
Gregor Mi wrote:
First of all, a clarification of this RR's intentions:
1) The original End Process... tooltip says you can always use
Ctrl+Alt+Esc... which is wrong as soon as someone changes the keyboard
shortcut exposed by KWin. So this should be fixed.
2) Make the Kill Window feature more discoverable. It is a seldom used
feature which makes it harder to remember.
About invoking Kill Window:
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself. [Martin]
...one could move the xkill functionality into KWindowSystem...
[Thomas]
Without knowing the amount of xkill code I suspect that having a dbus
call that loosly couples libksysguard to KWin is probably easier to maintain
than 2 times the xkill code.
Having said that, what about moving the xkill code to a common location
as Thomas suggested?
We do not guarantee that we don't change them, we do not guarantee that
they are exposed at all ... I do not want to run into situations that we
cannot change our code because external usage makes it impossible.
Understood. But would it then be possible at all to get the current
shortcut to display it to the user?
Martin Gräßlin wrote:
Ok, so this addresses two issues using one solution: exposing KWin's
internal shortcut. This is bad as outlined above.
I agree that 1) needs fixing. This can be done in the way as approached
in this review request: check whether kwin is registered on kglobalaccel and
get the key command. If it's done that way the fault is with libksysguard in
case KWin changes the shortcut name or doesn't use kglobalaccel any more.
Another fix is of course to just hide the shortcut.
2) is a different issue. Whether it's needed to expose the functionality
in addition from libksysguard is probably questionable. A better approach to
do this would be through a method in KWindowSystem. This does not need to
duplicate the code, it could also just send a client message to the window
manager to start the kill window process. Through KWindowSystem we can check
whether the feature is supported by the window manager and could exclude if
not supported. But and that's a big but: the feature would not be able to
work if it's triggered from a (context) menu or drop down list (it needs to
grab mouse). Given that I'm hesistant to say that it should be added to
kwindowsystem at all.
Thomas Lübking wrote:
ad 2)
I'd have said to rather *move* the code to KWindowSystem and use it from
there by any client (incl. kwin)
This allows porting the solution (in case such is possible on other
systems at all) as well as to invoke the feature unconditionally (ie. instead
of is this kwin? yes? tell kwin to trigger xkill. just trigger the xkill
functionality)
About the popupmenu:
The issue is global, ie. as long as a popup (or other grabber) is
around, the kwin shortcut neither works.
It's kind of the client codes problem to deal w/ a false return (eg.
invoke a timer and/or timered retries)
Gregor Mi wrote:
ad 1) (shortcut)
I could live with adapting (or remove) the shortcut retrieval as soon as
it will not be possible anymore. As long as it is, I would show it. (I
suspect as long as the shortcut is not hard-coded there will be a some way to
get it)
ad 2) (invoke window kill)
I looked a Kwin's source code. For reference, here are the two methods I
found to kill a window:
```
/*!
Kill Window feature, similar to xkill
*/
void Workspace::slotKillWindow()
{
if (m_windowKiller.isNull()) {
m_windowKiller.reset(new KillWindow());
}
m_windowKiller-start();
}
and
/**
* Kills
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On Jan. 26, 2015, 7:05 a.m., Martin Gräßlin wrote:
My opinion is that this is a feature which should not be exposed in
libksysguard. It actually ties libksysguard to KWin, while libksysguard was
in the past also used in e.g. kdevelop.
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself.
Martin Gräßlin wrote:
In addition: KWin's global shortcut action names are not public API. We
do not guarantee that we don't change them, we do not guarantee that they are
exposed at all (KWin handling shortcuts internally without kglobalaccel on
Wayland?). I do not want to run into situations that we cannot change our
code because external usage makes it impossible.
Thomas Lübking wrote:
In case there was larger demand for invoking such action (taskbar,
dedicated plasmoid, ...) one could move the xkill functionality into
KWindowSystem (option for portage) - invoking a kwin shortcut through a
kglobalaccel dbus call is a hack. Maybe sufficient for any downstream
solution, but easily broken feature.
Gregor Mi wrote:
First of all, a clarification of this RR's intentions:
1) The original End Process... tooltip says you can always use
Ctrl+Alt+Esc... which is wrong as soon as someone changes the keyboard
shortcut exposed by KWin. So this should be fixed.
2) Make the Kill Window feature more discoverable. It is a seldom used
feature which makes it harder to remember.
About invoking Kill Window:
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself. [Martin]
...one could move the xkill functionality into KWindowSystem...
[Thomas]
Without knowing the amount of xkill code I suspect that having a dbus
call that loosly couples libksysguard to KWin is probably easier to maintain
than 2 times the xkill code.
Having said that, what about moving the xkill code to a common location
as Thomas suggested?
We do not guarantee that we don't change them, we do not guarantee that
they are exposed at all ... I do not want to run into situations that we
cannot change our code because external usage makes it impossible.
Understood. But would it then be possible at all to get the current
shortcut to display it to the user?
Martin Gräßlin wrote:
Ok, so this addresses two issues using one solution: exposing KWin's
internal shortcut. This is bad as outlined above.
I agree that 1) needs fixing. This can be done in the way as approached
in this review request: check whether kwin is registered on kglobalaccel and
get the key command. If it's done that way the fault is with libksysguard in
case KWin changes the shortcut name or doesn't use kglobalaccel any more.
Another fix is of course to just hide the shortcut.
2) is a different issue. Whether it's needed to expose the functionality
in addition from libksysguard is probably questionable. A better approach to
do this would be through a method in KWindowSystem. This does not need to
duplicate the code, it could also just send a client message to the window
manager to start the kill window process. Through KWindowSystem we can check
whether the feature is supported by the window manager and could exclude if
not supported. But and that's a big but: the feature would not be able to
work if it's triggered from a (context) menu or drop down list (it needs to
grab mouse). Given that I'm hesistant to say that it should be added to
kwindowsystem at all.
Thomas Lübking wrote:
ad 2)
I'd have said to rather *move* the code to KWindowSystem and use it from
there by any client (incl. kwin)
This allows porting the solution (in case such is possible on other
systems at all) as well as to invoke the feature unconditionally (ie. instead
of is this kwin? yes? tell kwin to trigger xkill. just trigger the xkill
functionality)
About the popupmenu:
The issue is global, ie. as long as a popup (or other grabber) is
around, the kwin shortcut neither works.
It's kind of the client codes problem to deal w/ a false return (eg.
invoke a timer and/or timered retries)
Gregor Mi wrote:
ad 1) (shortcut)
I could live with adapting (or remove) the shortcut retrieval as soon as
it will not be possible anymore. As long as it is, I would show it. (I
suspect as long as the shortcut is not hard-coded there will be a some way to
get it)
ad 2) (invoke window kill)
I looked a Kwin's source code. For reference, here are the two methods I
found to kill a window:
```
/*!
Kill Window feature, similar to xkill
*/
void Workspace::slotKillWindow()
{
if (m_windowKiller.isNull()) {
m_windowKiller.reset(new KillWindow());
}
m_windowKiller-start();
}
and
/**
* Kills
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated Jan. 28, 2015, 8:35 p.m.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. Changes --- add screenshot 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. RR: Add a drop down menu to the End Process... button with one action: i18n(Kill a specific window... (Global shortcut: %1), killWindowShortcut) Diffs - processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 processui/keyboardshortcututil.h PRE-CREATION processui/keyboardshortcututil.cpp PRE-CREATION processui/ksysguardprocesslist.cpp 4dc142e864d8353ceafc3a6735ffa81e48291420 tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546 tests/keyboardshortcututiltest.h PRE-CREATION tests/keyboardshortcututiltest.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/122249/diff/ Testing --- File Attachments (updated) 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 Drop down shows Kill Window https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/58df12c5-7350-4bb0-b602-c5716caa9836__screenshot_default2.png Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On Jan. 26, 2015, 7:05 a.m., Martin Gräßlin wrote:
My opinion is that this is a feature which should not be exposed in
libksysguard. It actually ties libksysguard to KWin, while libksysguard was
in the past also used in e.g. kdevelop.
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself.
Martin Gräßlin wrote:
In addition: KWin's global shortcut action names are not public API. We
do not guarantee that we don't change them, we do not guarantee that they are
exposed at all (KWin handling shortcuts internally without kglobalaccel on
Wayland?). I do not want to run into situations that we cannot change our
code because external usage makes it impossible.
Thomas Lübking wrote:
In case there was larger demand for invoking such action (taskbar,
dedicated plasmoid, ...) one could move the xkill functionality into
KWindowSystem (option for portage) - invoking a kwin shortcut through a
kglobalaccel dbus call is a hack. Maybe sufficient for any downstream
solution, but easily broken feature.
Gregor Mi wrote:
First of all, a clarification of this RR's intentions:
1) The original End Process... tooltip says you can always use
Ctrl+Alt+Esc... which is wrong as soon as someone changes the keyboard
shortcut exposed by KWin. So this should be fixed.
2) Make the Kill Window feature more discoverable. It is a seldom used
feature which makes it harder to remember.
About invoking Kill Window:
If libksysguard wants to offer the functionality to kill a window, it
should implement it itself. [Martin]
...one could move the xkill functionality into KWindowSystem...
[Thomas]
Without knowing the amount of xkill code I suspect that having a dbus
call that loosly couples libksysguard to KWin is probably easier to maintain
than 2 times the xkill code.
Having said that, what about moving the xkill code to a common location
as Thomas suggested?
We do not guarantee that we don't change them, we do not guarantee that
they are exposed at all ... I do not want to run into situations that we
cannot change our code because external usage makes it impossible.
Understood. But would it then be possible at all to get the current
shortcut to display it to the user?
Martin Gräßlin wrote:
Ok, so this addresses two issues using one solution: exposing KWin's
internal shortcut. This is bad as outlined above.
I agree that 1) needs fixing. This can be done in the way as approached
in this review request: check whether kwin is registered on kglobalaccel and
get the key command. If it's done that way the fault is with libksysguard in
case KWin changes the shortcut name or doesn't use kglobalaccel any more.
Another fix is of course to just hide the shortcut.
2) is a different issue. Whether it's needed to expose the functionality
in addition from libksysguard is probably questionable. A better approach to
do this would be through a method in KWindowSystem. This does not need to
duplicate the code, it could also just send a client message to the window
manager to start the kill window process. Through KWindowSystem we can check
whether the feature is supported by the window manager and could exclude if
not supported. But and that's a big but: the feature would not be able to
work if it's triggered from a (context) menu or drop down list (it needs to
grab mouse). Given that I'm hesistant to say that it should be added to
kwindowsystem at all.
Thomas Lübking wrote:
ad 2)
I'd have said to rather *move* the code to KWindowSystem and use it from
there by any client (incl. kwin)
This allows porting the solution (in case such is possible on other
systems at all) as well as to invoke the feature unconditionally (ie. instead
of is this kwin? yes? tell kwin to trigger xkill. just trigger the xkill
functionality)
About the popupmenu:
The issue is global, ie. as long as a popup (or other grabber) is
around, the kwin shortcut neither works.
It's kind of the client codes problem to deal w/ a false return (eg.
invoke a timer and/or timered retries)
ad 1) (shortcut)
I could live with adapting (or remove) the shortcut retrieval as soon as it
will not be possible anymore. As long as it is, I would show it. (I suspect as
long as the shortcut is not hard-coded there will be a some way to get it)
ad 2) (invoke window kill)
I looked a Kwin's source code. For reference, here are the two methods I found
to kill a window:
```
/*!
Kill Window feature, similar to xkill
*/
void Workspace::slotKillWindow()
{
if (m_windowKiller.isNull()) {
m_windowKiller.reset(new KillWindow());
}
m_windowKiller-start();
}
and
/**
* Kills the window via XKill
*/
void Client::killWindow()
{
qCDebug(KWIN_CORE) Client::killWindow(): caption();
killProcess(false);
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On Jan. 26, 2015, 7:05 vorm., Martin Gräßlin wrote: My opinion is that this is a feature which should not be exposed in libksysguard. It actually ties libksysguard to KWin, while libksysguard was in the past also used in e.g. kdevelop. If libksysguard wants to offer the functionality to kill a window, it should implement it itself. Martin Gräßlin wrote: In addition: KWin's global shortcut action names are not public API. We do not guarantee that we don't change them, we do not guarantee that they are exposed at all (KWin handling shortcuts internally without kglobalaccel on Wayland?). I do not want to run into situations that we cannot change our code because external usage makes it impossible. Thomas Lübking wrote: In case there was larger demand for invoking such action (taskbar, dedicated plasmoid, ...) one could move the xkill functionality into KWindowSystem (option for portage) - invoking a kwin shortcut through a kglobalaccel dbus call is a hack. Maybe sufficient for any downstream solution, but easily broken feature. Gregor Mi wrote: First of all, a clarification of this RR's intentions: 1) The original End Process... tooltip says you can always use Ctrl+Alt+Esc... which is wrong as soon as someone changes the keyboard shortcut exposed by KWin. So this should be fixed. 2) Make the Kill Window feature more discoverable. It is a seldom used feature which makes it harder to remember. About invoking Kill Window: If libksysguard wants to offer the functionality to kill a window, it should implement it itself. [Martin] ...one could move the xkill functionality into KWindowSystem... [Thomas] Without knowing the amount of xkill code I suspect that having a dbus call that loosly couples libksysguard to KWin is probably easier to maintain than 2 times the xkill code. Having said that, what about moving the xkill code to a common location as Thomas suggested? We do not guarantee that we don't change them, we do not guarantee that they are exposed at all ... I do not want to run into situations that we cannot change our code because external usage makes it impossible. Understood. But would it then be possible at all to get the current shortcut to display it to the user? Martin Gräßlin wrote: Ok, so this addresses two issues using one solution: exposing KWin's internal shortcut. This is bad as outlined above. I agree that 1) needs fixing. This can be done in the way as approached in this review request: check whether kwin is registered on kglobalaccel and get the key command. If it's done that way the fault is with libksysguard in case KWin changes the shortcut name or doesn't use kglobalaccel any more. Another fix is of course to just hide the shortcut. 2) is a different issue. Whether it's needed to expose the functionality in addition from libksysguard is probably questionable. A better approach to do this would be through a method in KWindowSystem. This does not need to duplicate the code, it could also just send a client message to the window manager to start the kill window process. Through KWindowSystem we can check whether the feature is supported by the window manager and could exclude if not supported. But and that's a big but: the feature would not be able to work if it's triggered from a (context) menu or drop down list (it needs to grab mouse). Given that I'm hesistant to say that it should be added to kwindowsystem at all. ad 2) I'd have said to rather *move* the code to KWindowSystem and use it from there by any client (incl. kwin) This allows porting the solution (in case such is possible on other systems at all) as well as to invoke the feature unconditionally (ie. instead of is this kwin? yes? tell kwin to trigger xkill. just trigger the xkill functionality) About the popupmenu: The issue is global, ie. as long as a popup (or other grabber) is around, the kwin shortcut neither works. It's kind of the client codes problem to deal w/ a false return (eg. invoke a timer and/or timered retries) - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review74740 --- On Jan. 25, 2015, 6:21 nachm., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated Jan. 25, 2015, 6:21 nachm.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. Repository: libksysguard Description --- Current situation: The End Process... button has a tooltip which says To target a specific window to
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On Jan. 26, 2015, 7:05 a.m., Martin Gräßlin wrote: My opinion is that this is a feature which should not be exposed in libksysguard. It actually ties libksysguard to KWin, while libksysguard was in the past also used in e.g. kdevelop. If libksysguard wants to offer the functionality to kill a window, it should implement it itself. Martin Gräßlin wrote: In addition: KWin's global shortcut action names are not public API. We do not guarantee that we don't change them, we do not guarantee that they are exposed at all (KWin handling shortcuts internally without kglobalaccel on Wayland?). I do not want to run into situations that we cannot change our code because external usage makes it impossible. Thomas Lübking wrote: In case there was larger demand for invoking such action (taskbar, dedicated plasmoid, ...) one could move the xkill functionality into KWindowSystem (option for portage) - invoking a kwin shortcut through a kglobalaccel dbus call is a hack. Maybe sufficient for any downstream solution, but easily broken feature. First of all, a clarification of this RR's intentions: 1) The original End Process... tooltip says you can always use Ctrl+Alt+Esc... which is wrong as soon as someone changes the keyboard shortcut exposed by KWin. So this should be fixed. 2) Make the Kill Window feature more discoverable. It is a seldom used feature which makes it harder to remember. About invoking Kill Window: If libksysguard wants to offer the functionality to kill a window, it should implement it itself. [Martin] ...one could move the xkill functionality into KWindowSystem... [Thomas] Without knowing the amount of xkill code I suspect that having a dbus call that loosly couples libksysguard to KWin is probably easier to maintain than 2 times the xkill code. Having said that, what about moving the xkill code to a common location as Thomas suggested? We do not guarantee that we don't change them, we do not guarantee that they are exposed at all ... I do not want to run into situations that we cannot change our code because external usage makes it impossible. Understood. But would it then be possible at all to get the current shortcut to display it to the user? - Gregor --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review74740 --- On Jan. 25, 2015, 6:21 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, 2015, 6:21 p.m.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. 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. RR: Add a drop down menu to the End Process... button with one action: i18n(Kill a specific window... (Global shortcut: %1), killWindowShortcut) Diffs - processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 processui/keyboardshortcututil.h PRE-CREATION processui/keyboardshortcututil.cpp PRE-CREATION processui/ksysguardprocesslist.cpp 4dc142e864d8353ceafc3a6735ffa81e48291420 tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546 tests/keyboardshortcututiltest.h PRE-CREATION tests/keyboardshortcututiltest.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/122249/diff/ Testing --- Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On Jan. 26, 2015, 7:05 vorm., Martin Gräßlin wrote: My opinion is that this is a feature which should not be exposed in libksysguard. It actually ties libksysguard to KWin, while libksysguard was in the past also used in e.g. kdevelop. If libksysguard wants to offer the functionality to kill a window, it should implement it itself. Martin Gräßlin wrote: In addition: KWin's global shortcut action names are not public API. We do not guarantee that we don't change them, we do not guarantee that they are exposed at all (KWin handling shortcuts internally without kglobalaccel on Wayland?). I do not want to run into situations that we cannot change our code because external usage makes it impossible. In case there was larger demand for invoking such action (taskbar, dedicated plasmoid, ...) one could move the xkill functionality into KWindowSystem (option for portage) - invoking a kwin shortcut through a kglobalaccel dbus call is a hack. Maybe sufficient for any downstream solution, but easily broken feature. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review74740 --- On Jan. 25, 2015, 6:21 nachm., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated Jan. 25, 2015, 6:21 nachm.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. 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. RR: Add a drop down menu to the End Process... button with one action: i18n(Kill a specific window... (Global shortcut: %1), killWindowShortcut) Diffs - processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 processui/keyboardshortcututil.h PRE-CREATION processui/keyboardshortcututil.cpp PRE-CREATION processui/ksysguardprocesslist.cpp 4dc142e864d8353ceafc3a6735ffa81e48291420 tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546 tests/keyboardshortcututiltest.h PRE-CREATION tests/keyboardshortcututiltest.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/122249/diff/ Testing --- Thanks, Gregor Mi
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
On Jan. 26, 2015, 8:05 a.m., Martin Gräßlin wrote: My opinion is that this is a feature which should not be exposed in libksysguard. It actually ties libksysguard to KWin, while libksysguard was in the past also used in e.g. kdevelop. If libksysguard wants to offer the functionality to kill a window, it should implement it itself. Martin Gräßlin wrote: In addition: KWin's global shortcut action names are not public API. We do not guarantee that we don't change them, we do not guarantee that they are exposed at all (KWin handling shortcuts internally without kglobalaccel on Wayland?). I do not want to run into situations that we cannot change our code because external usage makes it impossible. Thomas Lübking wrote: In case there was larger demand for invoking such action (taskbar, dedicated plasmoid, ...) one could move the xkill functionality into KWindowSystem (option for portage) - invoking a kwin shortcut through a kglobalaccel dbus call is a hack. Maybe sufficient for any downstream solution, but easily broken feature. Gregor Mi wrote: First of all, a clarification of this RR's intentions: 1) The original End Process... tooltip says you can always use Ctrl+Alt+Esc... which is wrong as soon as someone changes the keyboard shortcut exposed by KWin. So this should be fixed. 2) Make the Kill Window feature more discoverable. It is a seldom used feature which makes it harder to remember. About invoking Kill Window: If libksysguard wants to offer the functionality to kill a window, it should implement it itself. [Martin] ...one could move the xkill functionality into KWindowSystem... [Thomas] Without knowing the amount of xkill code I suspect that having a dbus call that loosly couples libksysguard to KWin is probably easier to maintain than 2 times the xkill code. Having said that, what about moving the xkill code to a common location as Thomas suggested? We do not guarantee that we don't change them, we do not guarantee that they are exposed at all ... I do not want to run into situations that we cannot change our code because external usage makes it impossible. Understood. But would it then be possible at all to get the current shortcut to display it to the user? Ok, so this addresses two issues using one solution: exposing KWin's internal shortcut. This is bad as outlined above. I agree that 1) needs fixing. This can be done in the way as approached in this review request: check whether kwin is registered on kglobalaccel and get the key command. If it's done that way the fault is with libksysguard in case KWin changes the shortcut name or doesn't use kglobalaccel any more. Another fix is of course to just hide the shortcut. 2) is a different issue. Whether it's needed to expose the functionality in addition from libksysguard is probably questionable. A better approach to do this would be through a method in KWindowSystem. This does not need to duplicate the code, it could also just send a client message to the window manager to start the kill window process. Through KWindowSystem we can check whether the feature is supported by the window manager and could exclude if not supported. But and that's a big but: the feature would not be able to work if it's triggered from a (context) menu or drop down list (it needs to grab mouse). Given that I'm hesistant to say that it should be added to kwindowsystem at all. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review74740 --- On Jan. 25, 2015, 7:21 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, 2015, 7:21 p.m.) Review request for KDE Base Apps, Martin Gräßlin and John Tapsell. 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. RR: Add a drop down menu to the End Process... button with one action: i18n(Kill a specific window... (Global shortcut: %1), killWindowShortcut) Diffs - processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 processui/keyboardshortcututil.h PRE-CREATION processui/keyboardshortcututil.cpp PRE-CREATION processui/ksysguardprocesslist.cpp 4dc142e864d8353ceafc3a6735ffa81e48291420 tests/CMakeLists.txt 967b03fae1e460bfb22e1a07ef05cf7b49412546
