Support multi-layout keyboard setups#1
Open
UmutEmreOnder wants to merge 1 commit intoSporif:masterfrom
Open
Conversation
KWtype only searched the first XKB layout for keysym matches, so characters unique to a secondary layout (e.g. Turkish şçöğüı on an English+Turkish setup) were never found. They fell through to the Ctrl+Shift+U unicode fallback, which doesn't work in most applications. - Search all layouts in the keymap because the compositor reports a single keymap containing every configured layout, but the internal XKB state always defaults to layout 0. Relying on xkb_state_serialize_layout is wrong here since kwtype never receives layout-change events from the compositor to keep its state in sync. - Use KWin's DBus API (org.kde.KeyboardLayouts) to switch layouts at the compositor level instead of simulating shortcut keys. DBus is the correct interface because it is deterministic and avoids depending on user-configured keybindings. Poll getLayout after setLayout to wait for the compositor to confirm the switch before sending keys. - Restore the original layout after typing is complete so the user's keyboard state is not affected as a side effect. - Add missing <unistd.h> include for close() on newer GCC versions where implicit declarations are an error.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
KWtype only searches the active XKB layout for keysym matches. On multi-layout setups (e.g. English + Turkish), characters unique to the secondary layout (şçöğüı) are never found and fall through to the Ctrl+Shift+U unicode fallback, which doesn't work in most applications.
The root cause is that the compositor sends a single keymap containing all configured layouts, but kwtype's internal XKB state always defaults to layout 0 and never receives layout-change events to stay in sync.
Solution
org.kde.KeyboardLayouts.setLayout) to switch layouts at the compositor level when a character belongs to a different layoutgetLayoutaftersetLayoutto confirm the compositor has applied the switch before sending keysWhy DBus instead of simulating shortcut keys
DBus is deterministic and doesn't depend on user-configured keybindings (Meta+Space, Alt+Shift, etc.). It's KWin's official API for layout management.
Additional fix
<unistd.h>include forclose()— required on newer GCC versions (16+)