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.