Bug 567124 – proposal to delay doing something related to immodule until widgets realized

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 567124 - proposal to delay doing something related to immodule until widgets realized


Summary:	proposal to delay doing something related to immodule until widgets realized


Status:	RESOLVED FIXED

Product:	gtk+
Classification:	Platform
Component:	Input Methods
Version:	2.14.x
Hardware:	Other Linux

Importance:	Normal normal
Target Milestone:	---
Assigned To:	gtk-bugs
QA Contact:	gtk-bugs

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2009-01-09 06:14 UTC by Akira TAGOH
Modified:	2009-11-12 21:25 UTC

See Also:
GNOME target:	---
GNOME version:	---

Attachments
proposed patch (1.33 KB, patch) 2009-01-09 07:52 UTC, Akira TAGOH	committed	Details \| Review

Description Akira TAGOH 2009-01-09 06:14:00 UTC

For technical reason to obtain an immodule configuration through xsettings, gtk+ relies on the client window now. however there are the case where immodule instance is created before the client window is set. i.e. before "realize" method is invoked. once it's created, it won't be updated unless any changes is notified. this makes a trouble that the unexpected immodule is working on applications.

I'd suggest that would be better delaying any operations related to IM until widgets is realized.

Comment 1 Akira TAGOH 2009-01-09 07:52:26 UTC

Created attachment 126085 [details] [review]
proposed patch

Comment 2 Matthias Clasen 2009-01-13 05:53:16 UTC

Looks like a good idea to me.

Comment 3 Matthias Clasen 2009-01-23 06:04:14 UTC

        * gtk/gtktextview.c: Don't set up im stuff if the widget
        is not realized.

        * gtk/gtkimmodule.c: Assert that we have a window.

Comment 4 Tor Lillqvist 2009-01-29 15:16:55 UTC

After the last change to gtkimmulticontext.c on 2009-01-24, gtk-demo has started beeping once when it starts and once when it exits... Here is the top (bottom?) of a backtrace on X11 from the beep at start:

+ Trace 211986

#0 IA__gdk_window_beep
at gdkwindow-x11.c line 6074
#1 IA__gtk_widget_error_bell
at gtkwidget.c line 6973
#2 gtk_text_view_preedit_changed_handler
at gtktextview.c line 7326
#3 IA__g_cclosure_marshal_VOID__VOID
at gmarshal.c line 77
#4 IA__g_closure_invoke
at gclosure.c line 767
#5 signal_emit_unlocked_R
at gsignal.c line 3244
#6 IA__g_signal_emit_valist
at gsignal.c line 2977
#7 IA__g_signal_emit_by_name
at gsignal.c line 3071
#8 gtk_im_multicontext_set_slave
at gtkimmulticontext.c line 220
#9 gtk_im_multicontext_set_client_window
at gtkimmulticontext.c line 267
#10 IA__gtk_im_context_set_client_window
at gtkimcontext.c line 417
#11 text_window_realize
at gtktextview.c line 7960
#12 gtk_text_view_realize
at gtktextview.c line 3808

Comment 5 Akira TAGOH 2009-03-25 12:47:05 UTC

Matthias, sorry, I should check this carefully earlier, but your fix in r22214 didn't fixes the original issue I've described at the top of comments. because global_context_id held the unexpected value so that gtk_im_multicontext_get_slave() is invoked prior to gtk_im_multicontext_set_client_window(). so even if slave instance is reset when _set_client_window() is called, _get_slave() doesn't try to evaluate a context id through _gtk_im_module_get_default_context_id() that possibly may returns new id.

Comment 6 Akira TAGOH 2009-07-01 05:25:13 UTC

Any comments or thoughts?

Comment 7 Matthias Clasen 2009-07-01 05:44:19 UTC

No, I haven't looked at this yet, sorry.

Comment 8 Matthias Clasen 2009-09-04 22:17:26 UTC

Please try again with this change (will be in 2.17.11). It might fix your problem.

commit 1c0ecc0380f8e30df297c5f1156c11ce70c98c81
Author: Matthias Clasen <mclasen@redhat.com>
Date:   Fri Sep 4 18:09:44 2009 -0400

    Rework the way IM contexts are set
    
    Add a function to obtain the effective context id, and reset the slave
    only when the effective context id is different from the current context
    id, when setting a client window and on focus in. This might fix
    bug 593868 and bug 567124.

Comment 9 Jens Petersen 2009-09-14 05:17:13 UTC

I just tried 2.17.11 in fedora rawhide and with this I guess
chromium now picks up imsettings correctly.

Comment 10 Akira TAGOH 2009-09-14 05:42:14 UTC

Looks good now. thanks!

Comment 11 Javier Jardón (IRC: jjardon) 2009-11-12 21:25:17 UTC

Ok, marking as fixed then :)