GNOME Bugzilla – Bug 683463
signals refer to alias target types instead of aliases directly
Last modified: 2018-02-08 12:18:41 UTC
For instance, in a recently generated Gtk-3.0.gir I find the following: <glib:signal name="get-child-position" when="last"> <doc xml:whitespace="preserve"> [... snipped out docs ... ] </doc> <return-value transfer-ownership="none"> <type name="gboolean"/> </return-value> <parameters> <parameter name="widget" transfer-ownership="none"> <type name="Widget"/> </parameter> <parameter name="allocation" direction="out" caller-allocates="0" transfer-ownership="full"> <type name="cairo.RectangleInt"/> </parameter> </parameters> </glib:signal> The virtual-method for get_child_position is however correctly serialized with the correct GtkAllocation type. This must have something to do with the type being typedef'ed to a boxed type from cairo, and I suppose the signal introspection is grabbed directly from the actual boxed type provided to g_signal_new()
GtkAllocation is an alias to GdkRectangle, which is an alias to cairo.RectangleInt. g-ir-scanner handles GDK_RECTANGLE_TYPE specially, see workaround introduced in https://bugzilla.gnome.org/show_bug.cgi?id=655423#c6 I agree that this is not ideal. The basic problem is that GdkRectangle is alias to cairo.RectangleInt type, but both types are boxed and have different GType. Typelibs are simply not ready to cope with this, so we had to introduce workarounds to scanner.
Thanks for the comment... to lend some perspective on the problem, I don't need typelibs or intend to use them. I'm using GIR as an IDL to build a database of valid symbols, many things are possible such as generating the needed code to build a derived object class from an object class discovered with a GIR parser. The problem in this case is that a user will try to handle an 'event' originating from a GSignal, and they will get an undesirable calling signature that doesnt match up with the GObject's documentation. For instance: gboolean overlay_get_child_position (GtkOverlay *overlay, GtkWidget *widget, cairoRectangleInt *allocation, gpointer user_data) Which does work but is definitely sub-par. I do have some override files which allow me to correct the database for anything that a given set of GIRs get wrong (some of these cases are simply to ensure that deprecated symbols are not completely filtered out of the database, rendering them completely unusable) ... but I'd like to be able to use overrides as little as possible. I know, typelibs are popular and nowadays people are generally using them with libffi to implement bindings quickly, maybe typelibs are even the number one popular use case of GIRs today, but it would be nice to fix bugs in the right places as much as possible and keep GIR as pure of an IDL as possible (then perhaps their use wont be so limited to these typelibs...). Not sure exactly what it is about typelibs which cannot handle this, I suppose that the typelib implementation wants an unaliased and true structure definition for every GType, or at least for every boxed GType which declares a copy/free function for those structures, is it ?
(In reply to comment #2) > Not sure exactly what it is about typelibs which cannot handle this, > I suppose that the typelib implementation wants an unaliased and true > structure definition for every GType, or at least for every boxed > GType which declares a copy/free function for those structures, is it ? The problem is that GdkRectangle is basically alias (typedef) with its own GType, pointing to the target real type which has also its own, different GType. Typelibs do not store aliases, aliases are fully resolved when compiling .gir to .typelib. This means that at the end we dropped GType for GdkRectangle completely, because it is not possible to have one type (cairo.RectangleInt) having 2 gtypes (CAIRO_REACTANGLE_INT_TYPE and GDK_RECTANGLE_TYPE). The solution was to convert GDK_RECTANGLE_TYPE to CAIRO_RECTANGLE_INT_TYPE in the scanner's parser. This bug is direct outcome of this workaround :-( The clean solution for this problem would be e.g. allowing aliases to have its own GType. This is doable, but unfortunately means incompatible changes to typelib format, libgirepository api and (probably and most painfully) all bindings implementation changes to handle that.
I see, or perhaps I would get it more upon examining the typelib stuff more closely. If I understand the typelib itself is something which is compiled and you can link to with C code. Anyway the following is just a vague idea: Your answer leads me to wonder if it might be possible, without breaking the way the typelib works currently, to "spoof" aliased types (perhaps even, you dont want to allow alias resolving in the typelib itself as it might cause a lookup overhead, hence it's better to have them resolved there... not sure). What I mean by "spoofing" here is... perhaps a code segment like: typedef struct { int x; int y; int width; int height; } SpoofedGdkRectangle; ... could be generated and compiled into the typelib ... instead of actually trying to share the type you would then have some specific data type to work with and associate with GdkRectangle... I suppose older versions would still safely use the cairoRectangleInt type, and relinking with a new GIR to the updated typelib would cause the app to use the new struct... possibly without breaking any ABI rules. Anyway, as I said it's just an idea and I'm not familiar enough with the typelib stuff to really know how this stuff can break... Thanks for recognising this as a bug and not closing it in any case, I'm happy that we can at least agree this is indeed a bug :)
(In reply to comment #4) > If I understand the typelib itself is something which is compiled and you can > link to with C code. Well, not really. Typelib is basically information from .gir compiled by special tool (not C compiler) into binary blob saved to the disk (typically into /lib/girepository-1.0/Name-1.0.typelib). It is accessed exclusively by libgirepository library, which maps typelib file into memory and provides accessor APIs for accessing information from the typelib. > Your answer leads me to wonder if it might be possible, without breaking the > way the typelib works currently, to "spoof" aliased types (perhaps even, you > dont want to allow alias resolving in the typelib itself as it might cause > a lookup overhead, hence it's better to have them resolved there... not sure). sorry, I got lost and did not grasp your idea. Maybe it is too much based on the incorrect assumption you made above about what is a typelib? If not, I'll try to re-read and grasp it again. > Thanks for recognising this as a bug and not closing it in any case, I'm > happy that we can at least agree this is indeed a bug :) Well, I agree that it is a bug, or at least problematic behavior. The thing is that I'm not GI maintainer, I'm just user and occasional contributor, so my 'acknowledgment' here does not mean much :-)
(In reply to comment #5) > (In reply to comment #4) [...] > > Your answer leads me to wonder if it might be possible, without breaking the > > way the typelib works currently, to "spoof" aliased types (perhaps even, you > > dont want to allow alias resolving in the typelib itself as it might cause > > a lookup overhead, hence it's better to have them resolved there... not sure). > > sorry, I got lost and did not grasp your idea. Maybe it is too much based on > the incorrect assumption you made above about what is a typelib? If not, I'll > try to re-read and grasp it again. Yes it is indeed just an idea based on the incorrect assumption about how typelibs are compiled :) I basically just thought, if you're compiling the typelib anyway, why not just include an extra type definition into that compiled code for these corner cases... of course it does not apply here. > > Thanks for recognising this as a bug and not closing it in any case, I'm > > happy that we can at least agree this is indeed a bug :) > > Well, I agree that it is a bug, or at least problematic behavior. The thing is > that I'm not GI maintainer, I'm just user and occasional contributor, so my > 'acknowledgment' here does not mean much :-) Alrighty.. for the record I understand there are complications and dont need it to be fixed right now... but would be happy if there is some consideration on the issue. Since I depend on GIRs as well I would not mind contributing the patches to do this... but I guess that has to wait for some future defined api break at some point.
(In reply to comment #6) > > Alrighty.. for the record I understand there are complications and dont > need it to be fixed right now... but would be happy if there is some > consideration on the issue. Since I depend on GIRs as well I would not > mind contributing the patches to do this... but I guess that has to wait > for some future defined api break at some point. Adding more fields to the GIR is pretty easy, if that helps you. Changing the typelib and/or libgirepository API is much more involved.
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/72.