Composing sequences does not seem to be supported on KDE/Wayland. I am not sure which part of the software stack should be responsible for translating compose sequences into symbols. If I understood correctly, it should be handled by the compositor. But maybe a client-side input method would allow context dependent input. Reproducible: Always
No, compose-key needs to be done by the individual applications and it's Qt which does not handle it, see https://bugreports.qt.io/browse/QTBUG-54792 Compose-key is working correctly on any Xwayland window and on any GTK-Wayland window. Still KWin would also need compose-key support for internal things like the filter in Present Windows.
For KWin I just integrated a change to have compose key support. I'll try to get the same into Qt. commit a98a1b1376a3fdec5ce40f476e7a8a79a9f84b31 Author: Martin Gräßlin <mgraesslin@kde.org> Date: Mon Aug 29 17:04:13 2016 +0200 Support compose key in xkbcommon integration Summary: The Xkb class now creates a compose key table and a state object and feeds all key presses through the compose state machine. Xkb now tracks the latest keysym which is provided through new method currentKeysym. This is now used when creating a QKeyEvent instead of passing the key code to the xkb state. With that the keysym can also be updated through the compose state system. This only affects KWin internal usage where text is composed, e.g. the present windows effect filter. Wayland clients do not gain compose key support, though. Minimum xkbcommon version raised to 0.5 as compose key support is new in that version. Test Plan: Enabled compose key support in keymap and verified through DebugConsole Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2622
Created a code review against QtWayland, but there is already an older one which never got merged. Setting this report here to RESOLVED UPSTREAM. I tried what's possible.