GNOME Bugzilla – Bug 625540
cursor movement event for GtkIMContext
Last modified: 2018-04-15 00:17:43 UTC
Created attachment 166751 [details] [review] patch to notify cursor movement to GtkIMContext I would like to propose a mechanism to notify "cursor movement without focus change, only with mouse or cursor keys" event to GtkIMContext. Suppose that GtkTextView has some contents already and an immodule displaying its pre-edit buffer at the end of the contents. When a user clicks the existing contents he would expect the pre-edit buffer will be moved to that position as if he started pre-editing at the position. However, currently there are no notification from GtkTextView to GtkIMContext on that cursor movement. The attached is a patch to add "cursor_move" to capture the event (note that the patch currently checks only mouse events). I considered using "set_cursor_location" in combination with "filter_keypress". However, since "set_cursor_location" is designed to display tooltips and delivered asynchronously, we can't distinguish cursor movement from ordinary character input. Also, we could use "focus_in" in combination with "focus_out". However, some immodules (possibly not utilizing pre-edit buffers) wants to reset the context on "focus_out" and it breaks the compatibility. Comments and suggestions would be much appreciated.
Another rationale for this event is that it would be useful as a trigger of surrounding-text retrieval. BTW, the event name "cursor_move" might sound a bit misleading since there is already "set_cursor_location" where "cursor" means mouse cursor. Now I come up with a better name "caret_move" instead of "cursor_move". Actually AT-SPI provides an event with the similar name "object:text-caret-move".
Review of attachment 166751 [details] [review]: The idea looks plausible to me, but you don't seem to call cursor_move for all cursor moves in gtktextview ? And not at all for GtkEntry
Created attachment 220503 [details] [review] Emit "cursor-move" signal on every change of "insert" marker in GtkTextBuffer. Also support GtkEntry.
Sorry for late response. I updated the patch. Since this bug is about two years old, I don't remember the original intension, but it seems still useful for some IME (like Korean[1] and surrounding-text aware IME). The signal may be better renamed to "cursor-set" since the position might not change (or only emit the signal when the position actually changes?). 1. https://code.google.com/p/ibus/issues/detail?id=1420#c13
What would be really good to have is a test for this. Ideally automated tests, but an interactive test would be a great start. I know it won't be trivial, you probably need to write a mock immodule.
Created attachment 247225 [details] [review] imcontext: add "cursor-move" signal -- Forgot to propagate cursor_move in GtkIMMultiContext. Fixed.
Created attachment 247226 [details] [review] testsuite: add GtkIMContext tests -- So, here is the test.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new