Has your type already been registered in GObject type system?

Because both scim-chewing-0.3.1 and scim-anthy-1.2.3 include the same code from scim_color_button.cpp, and registered the same type name -- "ScimColorButton", when their setup UI modules are installed together, scim-helper-launcher would crash when loading them, since the later one would get an error and an invalid GType id (NULL).

Create a share object for "ScimColorButton"? I think for such a small class, it's not worth to do so.

To resolve this, one trick is to use g_type_from_name () (thanks the guys in #gtk+ on irc.gnome.org) to query, if the "ScimColorButton" is registered, if the GType returned is valid, stop to register. As following patch:

Index: src/scim_color_button.cpp
--- src/scim_color_button.cpp   (revision 794)
+++ src/scim_color_button.cpp   (working copy)
@@ -99,6 +99,9 @@
             (GInstanceInitFunc) scim_color_button_init,

+        type = g_type_from_name ("ScimColorButton");
+        if (!type)
         type = g_type_register_static (GTK_TYPE_DRAWING_AREA,
                                        &info, (GTypeFlags) 0);

The risk is if the 1st shared object is un-loaded, the 2nd module would fail to create the instance. If these two modules have same lifecycle, it's OK to use that method. Otherwise, name mangling would be better solution.

Leave a Reply

Your email address will not be published. Required fields are marked *

To submit your comment, click the image below where it asks you to...
Clickcha - The One-Click Captcha