flxzt
Input method preedit and cursor location reporting support
Describe the bug
Rnote's canvas does not have a nice support for IM in preedit mode, in IMMulticontext:
- The cursor position is not reported with
set_cursor_location(), which makes the IM candidate window stay at top-left corner. - The preedit text is not handled with
connect_preedit_{start,changed,end}.
To Reproduce
Steps to reproduce the behavior:
- Set up fcitx5 with https://github.com/wengxt/gnome-shell-extension-kimpanel, and env
GTK_IM_MODULE=fcitx - Open rnote, start typing with input methods requiring choosing candidate words (Pinyin, etc.)
- The preedit text is not shown, and the candidate window is at the wrong position.
Expected behavior
Preedit and candidate window position are working properly like in other GTK widgets.
Console Output
2024-08-01T06:16:45.831220Z DEBUG rnote: .. tracing subscriber initialized.
This didn't help.
Screenshots
https://github.com/user-attachments/assets/184e42a4-7bc5-4540-97f5-13ee8db0fd55
Desktop (please complete the following information):
- OS: Arch Linux
- App Version: 0.11.0
- Installation Source: Flatpak
- Desktop Environment: GNOME 46.3
- Display Server: Wayland
- Input Source: Keyboard, fcitx5 with gnome-shell-extension-kimpanel
Additional context
When testing with GNOME 46 Wayland with iBus in Fedora 40 in VM, it looks like the input method in canvas does not work at all without setting GTK_IM_MODULE=ibus (the default value is GTK_IM_MODULE=wayland). It looks like rnote is not handling text-input-v3 protocol well and I have no idea how to make that work.
The first part is the same issue as #1047. As you provided the functions to call (like connect_preedit_end), this should (hopefully) be easier to fix.
For the second part, I don't know either. It may be related to #771 in some way. As you're on fedora 40, can you install https://packages.fedoraproject.org/pkgs/gtk4/gtk4-devel-tools/ and launch gtk4-demo and see if you have the same issue with setting GTK_IM_MODULE manually for fcitx to work ? Or is it a canvas-specific issue (where the rest of the input entries work either way) ?
Oops, I tried searching before submitting this, but I didn't find #1047...
My configuration is Arch Linux + GNOME + fcitx5 as host, and Fedora 40 + GNOME + iBus as VM guest for testing. Either GTK_IM_MODULE=fcitx on host (fcitx5) and GTK_IM_MODULE=ibus on guest (iBus) works in rnote (with the preedit and cursor location bug in canvas), and GTK_IM_MODULE=wayland does not work at all with rnote's canvas on both host and guest VM. The GTK wayland IM module could interact with non-canvas widgets, with incorrect candidate window position:
GTK_IM_MODULE=wayland gtk4-demo works without issue on both configurations.
The canvas part is to be expected (need to implement things manually as you said).
The incorrect position with wayland is a bit strange though. Maybe a gtk+libadwaita bug on some configuration ?
Actually, do you have a code example where these functions are used ? I thought the docstrings would be enough to understand what's going on, but it wasn't the case. I still have no idea what goes inside connect_preedit_{start,changed,end}
Actually, do you have a code example where these functions are used ? I thought the docstrings would be enough to understand what's going on, but it wasn't the case. I still have no idea what goes inside
connect_preedit_{start,changed,end}
Sorry that I'm not very experienced in gtk programming, so I don't have a minimal example for this.
I found that maybe the implementation of gtktext in gtk4 could help in this case, where it handles signals preedit-start, preedit-changed, retrieve-surrounding and delete-surrounding. In gtk_text_preedit_changed_cb() it stores the preedit length and cursor location from gtk_im_context_get_preedit_string() from further usage. I didn't find any gtk-rs project for reference though.