On Thu Nov 2 13:46:33 2023 +0000, Alexandros Frantzis wrote:
Somehow I couldn't figure how to get the temporary text out of the xkb
compose state. I don't think there is a way to extract that info from the compose state. You will need to keep track of the temporary/dead xkb_keysyms, and emit the appropriate text manually as needed. I haven't yet looked at the KBDTABLES and IME part of this MR, but I assume we can do something similar to what winex11 (and experimental winewayland) do in ToUnicode, manually mapping from dead keys to wchar?
On GNOME the first keyboard layout is always used (even if it's not
the active one) when first creating a window. After investigating a bit, this turns out this is a bug in GNOME, since it violates the spec and does not send keyboard.modifiers after keyboard.enter as it should (it sends modifiers before enter). This is already known upstream, and I'll try to move the fix forward on the GNOME side. The [fix](https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3341) for this was merged and also backported to GNOME 44 and 45, so hopefully more users will be able to avoid the problematic behavior even if we decide not to implement the work around.
Looks like libxkbcommon 1.6 now has an API to inspect composition tables. This could be used to implement KBDTABLES dead key support, though the API is very recent.
I don't think the IME path is practical, at least not until the wayland driver has proper popup window positioning. Also, having to manually figure the conversion between dead keysym and temporary character doesn't feel very nice.
In any case this could take some time to implement (either dead key or another mechanism), and I think maybe it might be better to delay it until after the freeze.