SUMMARY When sending non-ascii keyboard characters into the active window, via custom keyboard shortcut, the characters are not arrived, and a random action is perofrmed. STEPS TO REPRODUCE 0. in "Custom Shortcuts", 1. define a keyboard action (New > Global Shortcut > Send Keyboard Input") 2. assign a shortcut key (I tried Meta+M, Meta+W, alt+ctrl+N) 3. assign a non-ascii, unicode string (I used €, or ₪) 4. Save. 5. open any app (e.g konsole, kate, browser) 6. Press the keyboard shortcut. OBSERVED RESULT 1. the keyboard input is not sent 2. The screen flickers briefly 3. (sometimes) the window manager act erratically (e.g. raising windows, change task, minimize/maximize, etc). EXPECTED RESULT the unicode character being "typed" into the app. (See details below) SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 20.04 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 ADDITIONAL INFORMATION 1. the settings in ~/.config/khotkeysrc seems "in order". The character is saved as UTF-8. 2. There's no bug when sending pure textual (a-zA-Z0-9) ASCII string 3. The same outcome happens when running a command / script that sends Unicode keys: STEPS TO REPRODUCE 1. sudo apt install xdotool 2. create an executable script using xdotool #!/bin/bash xdotool type € 3. Create a custom keyboard shortcut as above, but now choose "command/URL" OBSERVED RESULT same as above. EXPECTED RESULTS When this script works as standalone, it sens the unicode char to the active window. e.g. sleep 10 xdotool type € alt-tab to kate Here are my own guesses: * The unicode chars are sent in non-unicode encoding * the window manager is buggy in receiving certain keyboard input in certain conditions * the Meta keys are still (briefly) pressed when the event is fired, and they interfere with the emulated / automated keypress action. note: I opened a duplicate bug in khotkeys as 427509 , but - i'm not sure it belongs there, - I can't delete it there, - this bug report is much more clear / detailed.
*** Bug 427509 has been marked as a duplicate of this bug. ***
From this report, by sending a mixed string unicode+ascii, only the ascii pass. https://superuser.com/questions/1407480/how-to-insert-arbitrary-unicode-characters-in-kde-keyboard-shorctuts-send-keybo
i have an ugly but working workaround: 1. create this shell script: sleep 1 # or 2, depends how long you tend to keep the meta keys pressed. xdotool type € 2. assign the key-combo 3. when using (pressing) the key-combo, do it briefly, so the meta keys are not interfering with the keys being sent. 4. the unicode string will arrive to the active window correctly. Here's someone else's SO question: https://superuser.com/questions/1407480/how-to-insert-arbitrary-unicode-characters-in-kde-keyboard-shorctuts-send-keybo/1595086
As announced in https://pointieststick.com/2023/07/26/what-we-plan-to-remove-in-plasma-6/ and https://community.kde.org/Plasma/Plasma_6#Removals, I'm afraid KHotKeys has reached end-of-life in Plasma 6. Accordingly, all bug reports and feature requests for it must be closed now. Most of what KHotKeys could do can already be done with the newer KGlobalAccel system in Plasma 6. A few features such as mouse gestures and triggering conditions based on changes to window states are not yet implemented in the new system. These will be added in the future if and when resources materialize for them, and/or when a kind soul submits patches to implement them! :) Meanwhile, the 3rd-party "Mouse Actions" app (https://github.com/jersou/mouse-actions) may be usable for implementing your own mouse gestures again. Thanks for your understanding, everyone.