After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 165101 - There is no way to reset the IM context of a GtkTextView working only on the buffer
There is no way to reset the IM context of a GtkTextView working only on the ...
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkTextView
2.6.x
Other All
: Normal normal
: Small API
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2005-01-24 15:59 UTC by Paolo Maggi
Modified: 2018-02-10 03:42 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Paolo Maggi 2005-01-24 15:59:13 UTC
The undo manager of GtkSourceView operates only on the buffer and it has no
reference to views.
It needs a way to know when "preedit" is active or at least a way to "reset" the
IM context of the view.
This does not seem to be possible.
The only non obvious way I have found, i.e. changing the cursor position, does
not work since you get an "invalid iter" warning if you call
gtk_text_buffer_place_cursor when "preedit" is active.
We should probably add a gtk_text_buffer_force_im_context_reset function that
emits a "need_im_context_reset" signal that has to be catched by the views.

You can found some IRC log speaking of this problem here:

http://bugzilla.gnome.org/attachment.cgi?id=32596&action=view
http://bugzilla.gnome.org/show_bug.cgi?id=141993#c5
Comment 1 Owen Taylor 2005-01-24 17:53:25 UTC
Note that two views of the same buffer can have *different* preedit states.
Comment 2 Paolo Maggi 2005-01-25 08:49:25 UTC
This is true, but if I'm going to modify the buffer in a non interactive way
(for example, performing an Undo operation), all the views of the buffer should
reset their preedit state.
Comment 3 Paolo Maggi 2005-01-25 09:03:55 UTC
If you like my proposed solution, I can provide a patch.
Otherwise I will implement it in GtkSourceView (even it this case I will have to
access to private GtkTextView fields... see bug #163251).
Comment 4 Matthias Clasen 2008-07-11 20:33:35 UTC
The api you propose would probably work ok, but I wonder if it would be better to have something more general, like begin-noninteractive-operation and end-noninteractive-operation ? That would also protect against the user starting a preedit while your operation is still in progress (in case it is done asynchronously).
Comment 5 Matthias Clasen 2018-02-10 03:42:57 UTC
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.