Features request for Plasma KDE Wayland

[AlexBokhankovich]

What problem would this solve?

This will dramatically increase user experience

What would you like to happen?

• Add the ability to configure the keyboard layout switching key to Shift or CapsLock. Yes, I know that in KDE Plasma you can assign keys for layout switching - this works for CapsLock but does not work at all for Shift, because layout switching occurs at the moment the key is pressed down, so typing uppercase letters triggers a layout change. Ideally, the layout should only switch on a short single press of Shift, as implemented in Caramba Switcher https://caramba-switcher.com/.

• Add the ability to manually switch the layout of an incorrectly typed word by double-pressing Shift, as implemented in Caramba Switcher? mentioned above.

• Add the ability to manually switch the layout of selected text using the same key combination that is used for switching the layout of an incorrect word.

Which platforms does this concern?

Linux Wayland

Workarounds or alternatives you've considered (optional)

No response

[unv-unv]

I agree with CapsLock. In Windows I was using PuntoSwitcher with only manual layout switch on CapsLock. PolterType 0.18.1 doesn't even allow to rebind force-switch to CapsLock.

[iga566-gh]

Adding a second voice to this, with the reasoning behind both requests — I've been using
Punto Switcher for years and moved to PolterType this week (macOS + Windows, both machines).

1. Modifier-only chords (Ctrl+Shift, double-Shift)

This is the muscle memory of everyone coming from Punto/Caramba: the fix gesture is two modifiers,
pressed with the left hand, without a third key. The Hotkeys pane refuses it — the capture asks for
"at least one of Ctrl / Alt / Shift / Cmd" plus a regular key — and the restriction is structural
rather than a UI guard: HotKey::new(mods, Code) requires a key code, and chord_from_hotkey
returns None when the main key has no scancode entry, so the keystream path expects one too.

Since the engine already hooks the keyboard to see typing, the modifiers are visible to it. The
semantics that make this conflict-free are the ones Punto uses: fire on release, and only if no
other key was pressed between press and release. That is why Ctrl+C and Ctrl+V never trigger it.

2. Converting a selection

The current model — a buffer of the last word — covers the common case well. What it cannot do is
repair text that is already on screen: a whole sentence typed in the wrong layout, or a word the
detector deliberately left alone. Punto, Caramba, Mahou, KeyboardSwitch and RuSwitcher all solve
this the same way: select, press the key, the selection is converted.

The pieces PolterType would need are small: synthesizing a real ⌘C / Ctrl+C chord (today the
input layer emits Unicode strings, not modifier chords), reading and writing the clipboard, and
restoring what was in it. The conversion tables themselves already exist. The known traps are
timing (the clipboard is not available instantly), restoring non-text clipboard contents, and
password fields.

A note on priority from actual use: selection conversion matters mostly where auto-correction
missed. The better the detector, the less this is needed — and the detector here is good. So this
is a "when convenient" request, not a blocker. The modifier-only chord, on the other hand, is felt
every single day, because it is the gesture the hands already know.

Everything else has been a pleasant surprise: detection is accurate, the five-suggestion tooltip is
genuinely useful and picks sensible candidates, and the whole thing is fast with no hangs.

[vstrelnikof]

0.20.0 does one part of this, and it is the part that was a bug rather than a feature: the force-switch now works on the word you are still typing, not only on one already closed by a space. That is the type-notice-press gesture; until now it did nothing at all, which is also what #34 was reporting.

One caveat on that, since you are on macOS and Windows: it is measured working on KDE Plasma Wayland and GNOME Wayland, where the default chord is substituted to Ctrl+Shift+F9. An X11 run with the Backspace-based default switched a finished word correctly and did nothing mid-word, and I have not established why yet, so treat the mid-word case on a Ctrl+Shift+Backspace binding as unmeasured. If it does nothing for you, rebinding to a non-editing key is the thing to try, and I would like to hear either way.

The modifier-only chord is the right ask and is not in yet. @iga566-gh has it exactly: HotKey::new needs a key code, so it means moving both hotkeys onto the keystream matcher on every platform (the machinery is there — the suggestion digits already run that way everywhere) and adding the rule that makes it conflict-free: fire on release, and only if nothing else was pressed in between. That is a release of its own, and it is the next one on this list rather than a no.

Selection conversion stays behind it, for the reason given in the thread: it matters least where the detector is good.

On binding Caps Lock: on Wayland we observe the chord rather than consume it, so a Caps Lock binding would flip the lock and switch the word. That one needs the same keystream work before it can behave.

[vstrelnikof]

v0.21.0 has the modifier-only chord. Either hotkey can now be Shift+Shift — tap it twice — or two modifiers held together: Ctrl+Shift, Alt+Shift. Bind it the way you bind anything else: click Rebind on the Hotkeys pane and make the gesture.

The rule that keeps it out of everything else is the one @iga566-gh described: nothing fires on press. The chord is judged when the modifiers come back up, and only if nothing else was pressed while they were down — so Ctrl+C, Ctrl+Shift+V and typing capitals are untouched. A tap also has to be a tap: hold longer than half a second and nothing happens.

Measured in the desktop VM on all eleven sessions that correct at all — KDE Plasma Wayland, GNOME Wayland, sway, Cinnamon, Xfce, LXQt, i3, icewm, openbox, fluxbox — by typing a wrong-layout word, letting it auto-correct, then tapping Shift twice and reading the bytes back out of a terminal. The word comes back exactly as typed.

A single lone Shift is deliberately not offered. On Linux a mouse button reaches us as an event and cancels the gesture, but on Windows and macOS we do not see clicks at all, so a bare-Shift binding would fire on every Shift+click. Caps Lock stays out for the same kind of reason: we observe it rather than consume it, so binding it would flip the lock as well as switch the word.

Two things that came out of testing this and are also in 0.21.0: hotkeys used to arm up to 25 seconds after launch on sessions where GTK start-up blocks (sway), and a machine that had ever run GNOME could stop correcting in its other desktops entirely. Both fixed.

Selection conversion is still on the list, behind this.