Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
Gregor Mi
codestruct at posteo.org
Mon Jan 26 18:40:33 GMT 2015
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150126/1ba6b4b9/attachment.htm>
More information about the kde-core-devel
mailing list