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.

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

see also

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?

In T2050#210134, @davidedmundson wrote:

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?

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.

In T2050#235112, @davidedmundson wrote:

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.

In T2050#235181, @ngraham wrote:

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.

I'm the one that opened the above linked bug.

I have an Steelseries Apex Raw keyboard which has lots of extra keys.
Those keys are configured as F13-F29 and I use custom shortcuts to do all kinds of things using all the action types (keyboard input, dbus, commands).

Same for the mouse gestures and window actions.

I have mouse actions to change the volume, stop media playback, send keyboard input to browsers (new tab, close tab, refresh etc).
I also use window actions to change my mouse profile when I open/close Dota2.

Keyboard and mouse work thanks to these projects:
https://github.com/AstroSnail/apexctl
https://github.com/dokutan/mouse_m908