Created attachment 149833 [details]
On wayland

Also Note that the custom shortcuts that have been configured do still work, only adding, editing, etc is not possible, as the page is gone.

Custom Shortcuts are unreliable on Wayland so we have hidden the page by default for Wayland users. You can add any shortcuts you'd like using the Shortcuts page instead.

How would I go about doing that? I have found no way to connect a command to a shortcut with the regular shortcuts page.
There is a custom shortcuts service page, but it doesn't offer any configuration other than changing the hotkey for already created commands.
This seems a bit strange, all custom shortcuts were fine for me. 
Now I have to start X11 just to add and edit, while using them is still possible on wayland.

I urge you to reconsider this decision.

You make a script file and then assign a global shortcut to run it. It's a little clumsy, I know. We will improve it in the future.

Ultimately having two systems to do the same thing is silly, and on Wayland we've decided to focus on only one to de-confuse the UI.

I second vote to reconsider this, at least until there is no alternative implementation. Maybe there is some way to temporary force show that page? I tried `kcmshell5 kcm_hotkeys`, and it says there is no such module.

Currently we loose functionality to send dbus commands and send emulated keyboard input. But more importantly, it is not only about keyboard shortcuts. There are also Mouse Gestures and Window Actions in that menu.

I agree, the UI is confusing now. I reported my ideas in Bug 401628.

Sending emulated keyboard input and mouse gestures are pieces of functionality that don't work on Wayland. That was one of the big reasons we decided to hide this KCM--to avoid exposing features that are known to be broken, and that can't easily be made to work anytime soon given the fundamental architecture of Wayland.

Sending dbus commands is something you can do in a more awkward way with the Shortcuts page. You can add global shortcut to execute a script file that runs `dbus-send [whatever]`. This is fairly advanced functionality.

Thanks for clarification. And what about Window Actions? I used this functionality in X11. Despite window detection is broken there (Bug 401391), you can fill in the values, and window events (focusing, loosing focus, etc.) actually could trigger a command. I used that in my experimental project https://gitlab.com/AndrewShark/monitor-commander/-/blob/master/switch_preset.py to switch monitor preset based on active application. And I would like to have such possibility in Wayland.
But I guess this is redundant, and I probably could create some kinda "listener" kwin script, that will be notified about such events. If that is true, than dropping that config page is more than reasonable.

*** Bug 455765 has been marked as a duplicate of this bug. ***

Respectfully, I don't think this is the right decision.

I was using this feature to add custom bindings between keyboard combinations and commands, and it worked perfectly reliably - and still does. Today I found that when I wanted to add a new shortcut, the feature had disappeared - yet it did and still does work perfectly well.

Creating a new script file for every single shortcut is hugely impractical and a massive waste of time - not to mention the fact that for some users less familar with creating scripts, they may not properly understand how to do so. (To be honest, until I read this thread, I didn't realise I could bind a custom script with 'browse' and thought this was limited to desktop files for launching more conventional "apps".)

Also, since the feature still works well, I am much more inclined to go editing  ~/.config/khotkeysrc  to add my new shortcut than creating files that clutter up my disk. Yet this is now much more of a pain than the GUI was, and I am immediately nervous that I'll break something when I open up the file and see UUIDs...

On top of that, this creates an actual driving force towards X - why would you ever switch to Wayland if as soon as you do, you lose features? This actively hurts Wayland adoption, which seeing as Wayland is supposed to be the future, doesn't make any sense.

I understand that the motivation for this was to remove a "broken" feature - some of the options didn't work on Wayland, and providing a feature that won't work for a while doesn't make sense. But some of the options - very very useful options - work perfectly right now.
Would it not make more sense to remove only the option to create new shortcuts/actions that are known to not work? Or perhaps just leave them in with a warning that they won't work on Wayland for now?
(You may say this is unpolished, but arguably so is removing a feature like this - just removing it is confusing when users go looking for something they've been using before.)

Not only do some of the features of khotkeys not work on Wayland, its codebase is ancient and buggy and unmaintained. It does not work with modern components of the system and is slowly bit-rotting. Nobody wanted to touch it to disable the features in question on wayland because it is too fragile. Ultimately having two different GUIs to do the same thing is a bad idea and we made the decision for the Wayland session to focus on the one that is modern and maintainable, correcting an earlier mistake of allowing two parallel systems to be created in the first place.

The complaint about having to create a script file to use the other page is legitimate. Feel free to file a bug report about that in https://bugs.kde.org/enter_bug.cgi?product=systemsettings&component=kcm_keys.

Also, feel free to request features there for things that you miss from KHotkeys. The faster those are added, the sooner we can truly delete KHotkeys for everyone and remove the confusion and bugginess of two parallel overlapping global shortcut systems once and for all.

I understand. Thanks for your time.

I have filed a report as suggested (https://bugs.kde.org/show_bug.cgi?id=456951).

You're welcome!

*** Bug 457560 has been marked as a duplicate of this bug. ***

(In reply to Nate Graham from comment #5)
> You make a script file and then assign a global shortcut to run it. It's a
> little clumsy, I know. We will improve it in the future.
> 
> Ultimately having two systems to do the same thing is silly, and on Wayland
> we've decided to focus on only one to de-confuse the UI.

Hi,

I can't see any "global shortcut" entry in the shortcut settings menu. How can I find it ?

The correct page name on Wayland is just "Shortcuts."

So is the ability to add custom shortcuts gone? Is there even any way to add them in UI in wayland? In x11, it was DE agnostic with utilities like xbindkeys, but don't know if anything works similarly in wayland

Can I ask why I have been added to the CC list of this bug ?

When you post a comment on a bug report, you get CCd automatically. You can edit the CC list and remove yourself; there's a link to it in the top-right corner of the page.

As for the ability to add custom shortcuts, it's still there, but you do it now in the Shortcuts page. The workflow is a bit lousy and awkward compared to the old Custom Shortcuts page, which we're aware of; see Bug 456951 and Bug 440431. Hopefully this will be improved upon at some point.

(In reply to Nate Graham from comment #19)
> When you post a comment on a bug report, you get CCd automatically. You can
> edit the CC list and remove yourself; there's a link to it in the top-right
> corner of the page.
> 
> As for the ability to add custom shortcuts, it's still there, but you do it
> now in the Shortcuts page. The workflow is a bit lousy and awkward compared
> to the old Custom Shortcuts page, which we're aware of; see Bug 456951 and
> Bug 440431. Hopefully this will be improved upon at some point.

OMG I totally forgot that I commented on this one, sorry. I was confused because I created anothe bug a few weeks ago and I expected a mail from that one but not from this one here. Sorry for the silly question.

That's so fucked up. Why remove feature until replacement that reached feature parity is present?

> You can add any shortcuts you'd like using the Shortcuts page instead.

No, you can't. I have number of shortcuts that are just same script with different arguments. Right now you can't assign arguments to command and you can't edit command itself. You need to remove it and add as new "application".

*** Bug 462303 has been marked as a duplicate of this bug. ***

So what is the expected migration path for "Send keyboard input" shortcuts? I have a few to simulate missing keys from my notebook's built-in keyboard, and provide parity with some programs that are missing common shortcuts. What "application" can one add to to the other Shortcuts section that can perform equivalent actions?

At the moment, nothing. I'm not aware that such a thing is possible on Wayland right now.

@Roy, take a look at evsieve project, or other utility from https://wiki.archlinux.org/title/Input_remap_utilities.

Thanks, it looks very comprehensive for what it does, but I don't think it'll be suitable. The readme states "It is not a tool for keyboard macro's [sic] or complex event manipulation". I don't think there's a simple way to give it awareness of what the current program and its window properties are, and adjust keyboard bindings accordingly.

You are not right. See https://github.com/KarsMulder/evsieve/issues/18, and read that part with fifo socket. However, I do not currently know how to do a kwin script that will notify that socket, because window actions are also gone. See comment #8.

@AndrewShark I am confused as to whether you're saying it is or isn't possible. From your comments it seems the upgrade path is to learn the intricacies of evsieve to create desired mappings, create a system- or user-level systemd service to reliably run each evsieve invocation, add some relevant commands to a file in /etc/sudoers.d/ so that one can use sudo to write toggle instructions to the FIFOs without having to authenticate each time, and then not be able to trigger said toggles automatically anyway because there's nothing to run tasks based on specific windows gaining/losing focus.

Again, I do not think there will be a problem to emulate typing with one of the utilities. But regarding triggering by windows getting focus/loosing focus - I currently do not know how to read this info from kwin. Need to learn how it works.

> Also, feel free to request features there for things that you miss from KHotkeys.
I created Bug 462702 for Window Actions.

For those who want to ensure it is not working on Wayland or want to still access that kcm for deleting their shortcuts or just for ability to see how interface was made in that kcm, it is possible to show it. This commit hides it: https://invent.kde.org/plasma/khotkeys/-/commit/ed47291d1676dc0b9cddd75e3e0090cb5d3673c1
To show, comment that line in `/usr/share/kservices5/khotkeys.desktop`

*** Bug 463462 has been marked as a duplicate of this bug. ***

FWIW, the UX in Plasma 5.27 is much better, closer to what folks are used to from the old KHotKeys KCM.

Ok, I read the thread and I still strongly believe that this is poor design choice. Two easy example that I'm struggling with after trying to use Plasma Wayland for less than 20 minutes. I might have missed something, so please be gentle and correct me if I'm wrong. But here are the examples and later a brief conclusion:

## Example 1

I want to replace `rofi` (does not work on Wayland) with `fuzzel` or `wofi`. I have installed fuzzel using my distro's package manager, and I can run it from terminal and it works just fine. Now, I want to add a keyboard binding to run it. When I click on "+ Add Application..." button from the bottom middle column, I cannot find fuzzel. Another way would be to use sh/bash/zsh binaries and pass a command, none of those can be found either!! An alternative way can be to run a terminal (e.g alacritty or konsole) and make it to run a command, but guess what, after selecting Alacritty, I cannot pass any subcommands and arguments to that!!

## Example 2

Some software are dependent on subcommands. Flameshot is a good example (as I'm one of the maintainers). When I select Flameshot from the "+ Add Application..." menu, I cannot choose which subcommand to run and which what arguments.

## Conclusion

What you have done is forcing the user to create numerous scripts for the smallest things they want to do with their DE. None of the above examples are against the Wayland design or is restricted by Wayland protocol in any shape or form, and yet the Plasma Wayland is deliberately (or as you officially stated "intentionally") not letting the user to do the most basic action that all minimalistic window managers are letting user to do. You have also left users no guidance or choice! This is bad in another layer. I have been KDE Plasma user for over a decade, and yet I'm totally lost.

The UI for adding shortcuts for custom commands has been hugely improved to cover all those use cases in Plasma 5.27, which was released today.

From what I understand, there's a lot of progress with 5.27 release in configuring global shortcuts, both in Plasma as Nate said, and in apps with the Portal support https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/80

However there's no progress on Keyboard input (macros). As workaround, in addition to what's mentioned in https://wiki.archlinux.org/title/Input_remap_utilities there is also https://github.com/snyball/Hawck, but these tools are much harder to use and can make your system unusable, unlike the basic key input functionality in the old KCM.

Even after reading https://blog.martin-graesslin.com/blog/2016/12/how-input-works-keyboard-input/ something is not clear:
=> Can something be done in Kwin? Is even the compositor not permitted to inject keyboard events in the Wayland architecture?

*** Bug 469245 has been marked as a duplicate of this bug. ***

If you configure some hotkeys in x11 and re-login to wayland after that, the hotkeys continue to work, but the UI for their configuration is gone and cannot be opened. 

That looks like an inconsistency to me.

The reason why I still cling to using X11 is due to the convenience of its mouse gestures and global shortcuts. However, despite the rapid advancements in technology, these features have yet to be fixed even as of the current date of July 10, 2023. To my surprise, I recently downloaded Fedora KDE 38 and AlmaLinux KDE, both of which come equipped with Wayland and custom shortcuts that are fully functional and working flawlessly. This begs the question: How were these features implemented in Wayland, and is there a way to replicate them in Kubuntu? I am eager to know if anyone has any insights or suggestions on this matter.

>  both of which come equipped with Wayland and custom shortcuts that are fully functional and working flawlessly
This is False. I tried Fedora KDE 38 in Virtualbox and the Shortcuts page is the same as in Arch.
The problem here is that wayland lacks support of mouse gestures and other features described above.

Thanks Andrew for your time, I have checked again AlmaLinux was 5.24.6 so you are right; though Fedora had the basic functions (close, max, min, and present windows) of mouse gesture implemented,

Trying to change my Screenshot app in 5.27.9/Tumbleweed/Wayland.
Can somebody please explain how to do this?
No, I am NOT a developer, just a mere user...
Thanks.

Hi John,
Bug reports aren't the optimal place to ask for support questions. I'd recommend https://discuss.kde.org/c/help/6 instead.

Whoops...
Sort of relevant, just after a workaround until it's fixed... ;-)

There's nothing to fix; the old unmaintained "Custom Shortcuts" page in System Settings has been removed for Plasma 6, and was hidden in the Wayland session for Plasma 5 starting in 5.25. So this isn't a bug but rather an intentional decision. In its place is the newer actively maintained "Shortcuts" page in System Settings.

If you have further questions, including questions about how to migrate to the new system, I'd recommend asking them on https://discuss.kde.org/c/help/6, as I mentioned earlier.

>There's nothing to fix

Well, we've gone from a point-and-click interface that allowed users to draw gestures, select specific programs & windows and neatly organise things to enhance their desktop experience to ‘you can launch programs, maybe some specific actions if the program exposes them, or you can write your own software, it's not our problem.’ KDE knows this does not have the same specificity and is not nearly as accessible to users. That's not nothing, to me.

I understand that this specific KCM is not really fixable for Wayland, but it would be great if KDE could add _something_ to their roadmap. Having at least a plan for window/app targeting and a little input mapping as a nice-to-have feature would be preferable to this ‘go away’-style bug closure.

The missing piece is emulated input support in Plasma Wayland, and that requires someone to implement the support in kwin and xdg-desktop-portal-kde: https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12

Once that's in place, we'd have a framework to do fancier things in Wayland.