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

Reply via email to