sunsetting KHotKeys
Open, Needs TriagePublic

Details

Differential Revisions
D25086: Port to KGlobalAccel
jriddell added a subscriber: graesslin.

See https://mail.kde.org/pipermail/plasma-devel/2016-March/051178.html

Required actions will be:

  • add support to start applications in KGlobalAccel
  • migrate the existing KHotKey shortcuts to KGlobalAccel without the user

noticing

  • migrate the dbus command/fake input to shell scripts with a desktop file and

register them in KGlobalAccel

  • generate kwin scripts from the window actions

An idea can also be to improve the global shortcuts configuration module to
make it easier to set global shortcuts from there.

jriddell moved this task from To Do to Work in Progress on the Plasma board.Jul 7 2016, 1:43 PM

<notmart> Riddell: i'm working on a part of it

davidre added a subscriber: davidre.

As mentioned in T11567, we probably don't want to port khotkeys

One place where we still use khotkeys in plasma is in kmenuedit but that should be easily ported to GlobalAccel

Konsole still uses khotkeys (updatescript can be adapted from D19310 and D25086 since it writes itself into the kmenuedit group)

Good to see this porting in place. +++

With my Plasma hat on, is it worth leaving this alone till Plasma 6
(if it ain't broke...)

Or is it worth dropping before the next LTS so we don't have a burden to maintain?

Thoughts?

davidre moved this task from Backlog to In Progress on the KF6 board.Nov 25 2019, 9:28 PM

Good to see this porting in place. +++

With my Plasma hat on, is it worth leaving this alone till Plasma 6
(if it ain't broke...)

Or is it worth dropping before the next LTS so we don't have a burden to maintain?

Thoughts?

I think we can't remove it right now without having 100% feature parity. For example there is this weird action available by default that opens google in your browser (see https://cgit.kde.org/khotkeys.git/tree/data/defaults.khotkeys#n307).

As for things still needing porting I think it's only konsole and and skanlite (per lxr and trial and error for syntax: https://lxr.kde.org/search?_filestring=%2F*.khotkeys%24&_advanced=1&_string=)

There is also the case of the Konqueror gesture things? Are these gestures only local to Konqueror or are they somehow global and go for that reason through khotkeys? As I'm not a user of Konqueror maybe @dfaue can offer some insight?

fvogt added a subscriber: fvogt.Jul 10 2020, 1:07 PM

So far khotkeys was something which "just worked" and didn't need much work on it at all.

I know about some users who currently rely on khotkeys functionality to send arbitrary keypresses to windows and do arbitrary dbus calls.

I'm against dropping something which works just because it's unmaintained as long as there is no replacement.

Also, it seems like there's been some activity on master recently.

So far khotkeys was something which "just worked" and didn't need much work on it at all.

Some parts sucked. It being the default way for ksnapshot to launch was problematic as it created this application specific tie-in which caused many headaches.
I definitely want to make sure we migrate away from *relying* on it for core functionality.


I'm against dropping something which works just because it's unmaintained as long as there is no replacement.

Ack, the original position in the email was that it's mostly duplicating functionality that now exists scattered in other places.

I'm curious about the arbitrary keypresses usage, and understanding the workflow people have for that.
Is it overlapping with the advanced features of klipper or is it a way of doing shortcut remapping...

Also, it seems like there's been some activity on master recently.

Yeah, that would certainly trigger re-evaluation.

fvogt added a comment.Jul 10 2020, 2:28 PM

I'm against dropping something which works just because it's unmaintained as long as there is no replacement.

Ack, the original position in the email was that it's mostly duplicating functionality that now exists scattered in other places.

I'm curious about the arbitrary keypresses usage, and understanding the workflow people have for that.
Is it overlapping with the advanced features of klipper or is it a way of doing shortcut remapping...

The latter - in this particular case (https://bugzilla.opensuse.org/show_bug.cgi?id=1173968) it's about mouse gestures to trigger shortcuts in firefox.

In general I think it's sub-optimal to maintain two different tools that do essentially the same thing, even if both are working fine. It's confusing for users and it generates extra work for developers. If there are desirable things that KHotkeys can do which KGlobalAccel can't, IMO we should add the missing features to KGlobalAccel and continue with the plan to deprecate KHotKeys.

fvogt added a comment.Jul 11 2020, 9:39 AM

In general I think it's sub-optimal to maintain two different tools that do essentially the same thing, even if both are working fine.

That's not actually correct - kglobalaccel and khotkeys do totally different things. kglobalaccel provides a mechanism to emit signals or run .desktop file actions when a global shortcut got pressed and khotkeys provides a way to perform specific triggers (run command, call dbus, perform input) on specific actions (signal from kglobalaccel, mouse gesture, window state change).

It's confusing for users and it generates extra work for developers. If there are desirable things that KHotkeys can do which KGlobalAccel can't, IMO we should add the missing features to KGlobalAccel and continue with the plan to deprecate KHotKeys.

I'd also be in favor of merging the two.