GNOME Bugzilla – Bug 655423
GtkWidget::size-allocated is not introspectable
Last modified: 2015-02-07 17:01:31 UTC
This signal takes boxed GdkRectangle as an input argument. Unfortunately, Gdk.Rectangle is just an alias to cairo.RectangleInt, which is boxed type, but actually different than GdkRectangle (cairo.RectangleInt is boxed by cairo-gobject as 'CairoRectangleInt', while Gdk.Rectangle is boxed by gdk as 'GdkRectangle'). Since GdkRectangle is an alias, scanner does not associate gdk_rectangle_get_type() to it, and later, when parsing boxed argument of GtkWidget::size-allocated, it cannot find any type belonging to that gtype and marks signal unintrospectable.
Created attachment 192755 [details] [review] Forward _get_type() or GdkRectangle to CAIRO_GOBJECT_TYPE_RECTANGLE_INT Similarly as GdkRectangle is just typedef to cairo_rectangle_int_t, make GDK_TYPE_RECTANGLE and gdk_rectangle_get_type() just forward to CAIRO_GOBJECT_TYPE_RECTANGLE_INT. However this patch can be applied only after 2nd patch or some of its variation lands, otherwise it breaks gdk build (introspection step).
Created attachment 192757 [details] [review] Workaround to allow parsing GdkRectangle workaround This patch silences g-ir-scanner which chokes on libgdk exporting gtype with name not belonging to its namespace (g_type_name(GDK_TYPE_RECTANGLE) returns "CairoRectangleInt")
Hmmm. This is clearly an ugly case. I think that while the first patch may be OK, we should try to just handle this in the scanner too. Maybe we need to be able to associate GTypes with aliases?
One thing that adds to the complexity is that we resolve aliases when compiling the typelib. I think what we should do for now is just special case this entirely in the scanner. If we see Gdk.Rectangle, we Do The Right Thing. But we have to figure out what the Right Thing is. I think what we have to have in the typelib is cairo.RectangleInt. So maybe the scanner just entirely hides the existence of Gdk.Rectangle, and takes it out of the .gir too.
(In reply to comment #3) > Maybe we need to be able to associate GTypes with aliases? (In reply to comment #4) > One thing that adds to the complexity is that we resolve aliases when compiling > the typelib. Having aliases also in typelibs and allowing them to have GTypes would solve this problem cleanly and in a generic way. But I'm not sure if aliases in typelibs can be expressed by existing g-i C API in backward-compatible way, so that existing consumers (bindings) don't have to add code for handling aliases. > I think what we should do for now is just special case this entirely in the > scanner. If we see Gdk.Rectangle, we Do The Right Thing. > But we have to figure out what the Right Thing is. I think what we have to > have in the typelib is cairo.RectangleInt. Right, agreed. > So maybe the scanner just entirely > hides the existence of Gdk.Rectangle, and takes it out of the .gir too. Leaving GdkRectangle alias out of Gdk.gir completely would mean that scanner will have to handle also all references from foreign .girs (e.g. Gtk.gir references Gdk.Rectangle, we would have to turn all references to Gdk.Rectangle into cairo.RectangleInt while compiling Gtk.gir). If we go through this workaround way, it would probably be enough to leave Gdk.Rectangle alias in and just turn all GType references of "GdkRectangle" to "CairoRectangleInt".
Created attachment 193028 [details] [review] Turn GdkRectangle gtype into CairoRectangleInt on first sight As per previous comment, this patch turns all references to GdkRectangle gtype into CairoRectangleInt one. This means that patching gdk is not needed any more.
Review of attachment 193028 [details] [review]: So with this patch we're just hiding the existence of the GdkRectangle GType, but keeping it in the .gir? I think that makes sense - we can't remove Gdk.Rectangle entirely because it's possible someone was using it from client code.
Review of attachment 193028 [details] [review]: Exactly. Thanks for the review!
Reopening, there is still one failure after the committed patch. Calling g_irepository_find_by_gtype(GDK_TYPE_RECTANGLE) returns NULL, because there is no trace of GDK_TYPE_RECTANGLE (a.k.a. 'GdkRectangle') in the typelib.
Created attachment 194326 [details] [review] Convert GdkRectangle to CairoRectnagleInt also on girepository C API side One possible solution is in this patch. This basically mirrors the same hack which was added into the scanner into C API.
Review of attachment 194326 [details] [review]: Hmm, what "user code" would be calling this? I guess it's probably OK as a patch, but I want to know what concrete problem you hit without this patch.
(In reply to comment #11) > Review of attachment 194326 [details] [review]: > > Hmm, what "user code" would be calling this? I guess it's probably OK as a > patch, but I want to know what concrete problem you hit without this patch. When binding implementation wants to get/set property, it can use either GI-based approach (g_property_info_xxx() funcs), or just GLib facilities. Although former is probably preferred, there are cases when latter is still needed (e.g. gstreamer uses dynamic properties, which are not present in the gir). In this case, binding implementation queries the type of the property (using g_object_class_find_property()), and it gets GDK_TYPE_RECTANGLE, and without the patch it cannot map it to any known type. The same applies also to signals.
Review of attachment 194326 [details] [review]: (In reply to comment #12) > (In reply to comment #11) > > Review of attachment 194326 [details] [review] [details]: > > > > Hmm, what "user code" would be calling this? I guess it's probably OK as a > > patch, but I want to know what concrete problem you hit without this patch. > > When binding implementation wants to get/set property, it can use either > GI-based approach (g_property_info_xxx() funcs), or just GLib facilities. > Although former is probably preferred, there are cases when latter is still > needed (e.g. gstreamer uses dynamic properties, which are not present in the > gir). In this case, binding implementation queries the type of the property > (using g_object_class_find_property()), and it gets GDK_TYPE_RECTANGLE, and > without the patch it cannot map it to any known type. > > The same applies also to signals. Thanks, that's the kind of real-world case that's important to understand. Having it in the bug here is probably fine, but if you like you could copy it into the commit message too.
Review of attachment 194326 [details] [review]: Committed with usecase description. Thanks for the review!
Review of attachment 194326 [details] [review]: Committed with usecase added into the description. Thanks for the review!
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]