many of my KDE DE (@ Fedora, mostly, but not exclusively) instances use CustomShortcuts for a11y users' (in addition to others', generally) support -- via khotkeys/kglobalaccel et al available under X11 with the impending/inevitable switch to wayland, this, ``` Custom Shortcuts are gone in 5.25 on Wayland https://bugs.kde.org/show_bug.cgi?id=455444 ``` says "CLOSED INTENTIONAL" & 'ask in support channels' in support channels, asking for methods/docs/examples of how to, press a trigger chord (e.g. Control+Opt+Cmd+T) and have a string of chars (e.g., "T e s t !") typed-out in the active window , nothing as yet forthcoming. under kde/wayland, it's clear how to have a chord trigger exec of an app/script @ System Settings -> Shortcuts -> Custom Shortcuts Service there does not appear (?) to be a method in the UI to specify a string of characters to be typed, as is done under X11, where it's clean/elegant/trivial, @ SystemSettings -> CustomShortcuts create new shortcut add Comment assign Trigger e.g., Meta+Ctrl+Alt+T enter Action e.g., Shift+t:e:s:t:Shift+1 in any/all apps, then, chord-press of "Meta+Ctrl+Alt+T" types out : "Test!" the X11 solution is not 'hacky', is end-user usable -- particularly by/for a11y users, demonstrated & in-use here for ages -- and at least for awhile, was deployed as 'officially included' in the KDE SystemSettings UI. Under Wayland, we need some equivalent in-UI solution to roll out to real, a11y-using end-users. Something non-coder end-users can setup/modify/use. And can be easily configured and deployed to multiple end-user machines.
for info/ref, from KDE/X11's CustomShortcuts' Example == "Type Hello", "After pressing Alt+Ctrl+H the input of 'Hello' will be simulated, as if you typed it. This is especially useful if you have call to frequently type a word (for instance, 'unsigned'). Every keypress in the input is separated by a colon ':'. Note that the keypresses literally mean keypresses, so you have to write what you would press on the keyboard. In the table below, the left column shows the input and the right column shows what to type. "enter" (i.e. new line) Enter or Return a (i.e. small a) A A (i.e. capital a) Shift+A : (colon) Shift+; ' ' (space) Space"
fyi, from a comment in #fedora-kde "the emulated input support needed for what you want is not yet implemented, https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12"
I'm not sure this counts as wishlist level? It's something that is used as an accessibility feature.
Can you elaborate a bit on the use case? Is this primarily about typing in text? Or more generally about UI automation, e.g. by triggering shortcuts in the application?
(In reply to Nicolas Fella from comment #4) > Can you elaborate a bit on the use case? Is this primarily about typing in > text? Or more generally about UI automation, e.g. by triggering shortcuts in > the application? Typing text. Exactly as given in the examples above, in https://bugs.kde.org/show_bug.cgi?id=478219#c0 https://bugs.kde.org/show_bug.cgi?id=478219#c1
I'm asking because it potentially makes a difference in how we present this in the UI. Users specifying "Hello" as input seems more friendly than "Shift+H:E:L:L:O"
Also, not every text is easily typeable via keystrokes on every keyboard layout (particularly non-latin/CJK text), so shifting the mental model from keystrokes towards text input makes sense
Random aside: The builtin "Type 'Hello'" example in khotkeys is broken. It only types "hello". This is because the shortcut uses H so it swallows the first letter
> Users specifying "Hello" as input seems more friendly than "Shift+H:E:L:L:O" couldn't agree more. that's what existed. and what we made do with. frequently, complex strings to be typed have to be 'assembled' _for_ the user, and assigned to a manageable key-chord. a PITA, but doable -- and deployable. it would be a great improvement to be able to 'enter' a string to be typed, simply by typing it -- not synthesizing it. e.g., 'simply' TEXT to type: [ p@s$w0rD_1 ] KEY COMBO: Ctrl-Meta-P or, TEXT to type: [ (tab)Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. (return)(return)Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. ] KEY COMBO: Ctrl-Shift-Meta-L and, when KEY-COMBO is played in active window (Konsole, LibreOffice, Firefox URL bar, etc etc), the TEXT would be typed, as input.
This is not fixed, so reopening.
*** Bug 488383 has been marked as a duplicate of this bug. ***
Why did you mark this as UNMAINTAINED? It was previously CONFIRMED, meaning we acknowledge it's a thing that's missing and needs to be added. Re-opening.
FYI, libxkbcommon supports outputting multiple keysyms, so it could be handled at the XKB level (Wayland-only). We need a keymap builder API in libxkbcommon so that configuring this feature can be done in the GUI, because it is not realistic to ask to all users to write custom XKB. However, motivated users can already experiment this feature, documented at: https://xkbcommon.org/doc/current/keymap-text-format-v1.html#key-symbols-table, with User configuration (https://xkbcommon.org/doc/current/user-configuration.html): key <XXXX> { [ {f, o, o}, "bar" ] }; Note that the user-friendly string syntax is a recent addition (since libxkbcommon 1.10). libxkbcommon 1.11 will be published soon; I plan to work on the keymap builder API in 1.12.
That sounds interesting. Could "key <XXXX>" be a keyboard shortcut using modifier keys?
(In reply to Nate Graham from comment #14) > That sounds interesting. Could "key <XXXX>" be a keyboard shortcut using > modifier keys? Not exactly: the `key <XXXX> { … }` statement declares a lookup table (level → keysyms + actions) for a *single* keycode. It then requires another lookup table, a key type, which maps modifier *states* to levels. E.g. for an alphanum key of a Latin script, the mapping is typically: - no active modifier → level 1 - shift → level 2 - caps → level 2 - shift + caps → level 1 - (scripts requiring AltGr have more entries, on the same model) As you can see, it does not map directly key combos, but rather modifier combos. There are 2 limits to this approach: 1. If one changes the type of a key in order to add the shortcuts, it has to be done carefully so that every combination of modifiers works as intended on the key. 2. Apps struggle to respect some XKB concepts, most notably the *consumed modifiers*. E.g. If you map "Test !" to Meta+Ctrl+Alt+T as proposed by the OP, then apps should not interpret the modifiers Meta+Ctrl+Alt, because they have been “consumed” to produce the text output. Let me provide you a somehow similar use case I am trying to solve: some people are used to “Ctrl+Alt” (2 keys) on Windows instead of AltGr, which produces the same modifiers but with only 1 key. They naturally want to use the same on Linux, but it remains difficult because all my current attempts failed due to apps interpreting Control or Alt although they are consumed (e.g. Konsole does it). Because of the incorrect implementation *in the apps*, what can be achieved with XKB is unfortunately limited. I have some ideas to mitigate this, but I am quite alone working on libxkbcommon, so it takes time. The keymap API seems an important milestone to me, the next one being mitigating the poor use of XKB in apps.
But wait: wouldn’t *input methods* be more adapted for this task? E.g. detect a modifier state and output specific string when matching some key combos? If Plasma could provide a simple IM, it could handle Compose, Unicode input (Ctrl+U+code point), emoji and… custom strings!
> But wait: wouldn’t *input methods* be more adapted for this task? E.g. detect a modifier state and output specific string when matching some key combos? Indeed, on our Input Goal proposal at https://phabricator.kde.org/T17433, we included a bullet point "Expand configurable strings into pre-defined snippets" in the "Better IME support" section. I see no reason why an input method couldn't also handle shortcuts with modifiers to do the same thing. However, if the user already relies on a different input method, we will have to improve quick-switching between their current input method and this proposed new one. This ties back into https://invent.kde.org/teams/goals/we-care-about-your-input/-/issues/13 again. On the other hand, I also sneakily included a text snippet action into our designs for touch/stroke gesture actions, in https://invent.kde.org/teams/vdg/issues/-/issues/99 (Gesture Customization UX), search for "Assigning emulated key presses". This makes me think that perhaps an input method by itself is too limited a use case, and we may want to consider this kind of action as part of an overall Plasma/KWin automation push. I wonder if perhaps a KWin plugin is the right way to add this. I guess if it were a built-in input method, the plugin could briefly enable this IM and then switch back to whatever was active before. Lots of options to implement this. Also note that this bug report is listed on https://community.kde.org/Plasma/Wayland_Known_Significant_Issues#Keyboard/typing right now.