fix: improve reliability of dead key and compose key handling with the overlays
Reason for the change
We were trying to track the compose state ourselves while still passing the keys through to the compositor, but this is problematic because some applications/toolkits (for example Signal, Telegram, and Chromium have been identified) will send a surrounding_text changed event for the compose/dead key (to e.g. visually show a change), but this surrounding_text change event caused our tracking to think the compose sequence was finished or cancelled, aborting the sequence and breaking the compose/dead key handling.
Instead we use the actual xkbcommon state machine to keep track of the compose state (which makes better sense than trying to implement our own), and do not pass such compose keys through to the compositor at all; thus we don't have to worry about misbehaving applications/toolkits sending unexpected events that break the key handling.
Test plan
Tests for both dead keys and compose sequences have been added.
To test the changes:
- With plasma-keyboard & its hardware diacritics popups enabled..
- Verify compose sequences work; e.g.
<compose>+t+m=™ - Using a keyboard layout with dead keys, verify dead keys work; e.g. with en_US intl w/dead keys
'+a=á - Verify compose sequences still work with a dead keys layout (if switched from a non-dead keys layout)
Bugs fixed
FIXED-IN: 6.7.0