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 572415 - Have glib:ref-function, glib:unref-function, glib:copy-function and glib:free-function attributes where appropriate
Have glib:ref-function, glib:unref-function, glib:copy-function and glib:free...
Status: RESOLVED OBSOLETE
Product: gobject-introspection
Classification: Platform
Component: g-ir-scanner
2.18.x
Other All
: Normal enhancement
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks: 559704 720090
 
 
Reported: 2009-02-19 14:04 UTC by Didier "Ptitjes"
Modified: 2018-02-08 11:49 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
Makes GMainLoop boxed as many similar GLib types already are (2.24 KB, patch)
2010-09-07 14:51 UTC, Pavel Holejsovsky
none Details | Review
GLib.gir and typelib taught about GLib structs boxed by libgobject (2.80 KB, patch)
2010-09-07 14:55 UTC, Pavel Holejsovsky
none Details | Review
Make MainLoop and related structures boxed. (2.24 KB, patch)
2010-09-07 17:12 UTC, Pavel Holejsovsky
none Details | Review
Make more GLib structures boxed by libgobject. (3.78 KB, patch)
2010-09-08 13:14 UTC, Pavel Holejsovsky
none Details | Review
Recognize GLib structures boxed by libgobject. (3.02 KB, patch)
2010-09-08 13:15 UTC, Pavel Holejsovsky
none Details | Review

Description Didier "Ptitjes" 2009-02-19 14:04:42 UTC
There is gir annotation for:
- ref and unref function for classes
- copy and free function for structs

These informations are mandatory for bindings to behave appropriately.
Comment 1 Colin Walters 2009-02-20 22:38:36 UTC
GBoxed has copy and free for structures (well, it's not strictly speaking right to use GBoxed for this, but it works OK in practice).

ref/unref for classes sounds like the "non-GObject class" problem, which is definitely trickier than just ref/unref functions.  Right now <class> means GObject.  If we want to accomodate other things (and I'm not opposed to that) it needs toplevel design discussion first.  

Comment 2 Jürg Billeter 2009-02-21 11:48:04 UTC
Not all structures are GBoxed registered, so we probably still need such attributes, although the `c' namespace might make more sense.

We definitively need more than just ref/unref for non-GObject classes. I'll try to come up with a proposal.
Comment 3 Colin Walters 2009-02-23 15:44:00 UTC
Ok, let's make this bug about ref/unref/free for structures, the classes should be a separate bug.

How should we determine ref/unref/free?  Automatically from the name (look for _ref at the end)?  An annotation?  
Comment 4 Dan Winship 2009-02-23 18:24:54 UTC
automatic would be nice. it seems like the "generic annotations" support in bug 571548 would let you specify them beyond that, assuming that the namespaces got mapped right...
Comment 5 Colin Walters 2009-02-23 20:45:37 UTC
Yeah, we can probably pretty safely assume that a function ending in _ref on a C struct is a ref function, though we may need an annotation to override that.

Like my comment on the non-GObject classes, the main question here is what impact struct refs has on bindings.  Right now introspection and most implemented bindings are based on a GObject world.

I'm assuming bindings would need to respect (transfer) for refcounted structures?  What is the default for (transfer) and ref-structs?  We need to look at some cases/sample code and see how this would be used.

Comment 6 Andreas Rottmann 2010-09-04 14:47:10 UTC
This affects for example GLib.MainLoop, which is unusable with current
gobject-introspection HEAD. Its constructor (g_main_loop_new) is
marked as `introspectible="0"', since it returns a pointer to a
non-boxable record type. Several other types in GLib are affected as
well (e.g. GIOChannel).

I'm not clear on how this should be resolved; do we need to add extra
fields (ref_func, unref_func) to StructBlob and UnionBlob?
Comment 7 Pavel Holejsovsky 2010-09-06 12:44:58 UTC
(In reply to comment #6)
> I'm not clear on how this should be resolved; do we need to add extra
> fields (ref_func, unref_func) to StructBlob and UnionBlob?

I'd vote for 'structs can be used by introspection only when boxed' approach, as it is in current gobject-introspection HEAD.  This not only solves ref/unref functions problem, but also assigns typeid so it makes bindings implementation easier when checking types when passing them to called functions.

I'm not sure how realistic is the requirement to have all introspectable structures boxed, though.  Would there be any opposition in GLib to add G_DEFINE_BOXED for GMainLoop, GTimer, GIOChannel, GChecksum, GDir, GKeyFile, GMappedFile, GRegex etc... ?
Comment 8 Andreas Rottmann 2010-09-06 13:36:20 UTC
(In reply to comment #7)
> 
> I'm not sure how realistic is the requirement to have all introspectable
> structures boxed, though.  Would there be any opposition in GLib to add
> G_DEFINE_BOXED for GMainLoop, GTimer, GIOChannel, GChecksum, GDir, GKeyFile,
> GMappedFile, GRegex etc... ?
>
Is this even possible for GLib? I think boxing is a feature of the
GObject library, hence unavailable in GLib. If I'm not off track here,
we really need this feature, or GLib will not be bindable.
Comment 9 Pavel Holejsovsky 2010-09-06 13:55:13 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > 
> > I'm not sure how realistic is the requirement to have all introspectable
> > structures boxed, though.  Would there be any opposition in GLib to add
> > G_DEFINE_BOXED for GMainLoop, GTimer, GIOChannel, GChecksum, GDir, GKeyFile,
> > GMappedFile, GRegex etc... ?
> >
> Is this even possible for GLib? I think boxing is a feature of the
> GObject library, hence unavailable in GLib. If I'm not off track here,
> we really need this feature, or GLib will not be bindable.

Ouch. That's right.  Maybe GObject library could provide boxing for GLib types (in the same way as GObjectIntrospection provides typelibs for GLib/GObject/etc.)  But you are right, this makes my proposed solution even less atractive :-(
Comment 10 Johan (not receiving bugmail) Dahlin 2010-09-06 14:00:41 UTC
GObject already registers a bunch of boxed types:
http://git.gnome.org/browse/glib/tree/gobject/gboxed.c?id=e35ed21f43f94443e5b137d85120b87542261c5b#n123

It makes sense to register the remaining types in glib there, as long as the boxed semantics are suitable for these objects.
Comment 11 Pavel Holejsovsky 2010-09-06 14:12:48 UTC
(In reply to comment #10)

AFAIK GMainLoop has ref/unref methods, so boxing it should be without problems.  But the problem is that g-ir-scanner does not currently pick these up, most probably because structs are defined in GLib namespace, while appropriate _get_type() methods are in GObject namespace.
Comment 12 Pavel Holejsovsky 2010-09-07 14:51:21 UTC
Created attachment 169674 [details] [review]
Makes GMainLoop boxed as many similar GLib types already are

Prerequisite for the next patch.
Comment 13 Pavel Holejsovsky 2010-09-07 14:55:02 UTC
Created attachment 169675 [details] [review]
GLib.gir and typelib taught about GLib structs boxed by libgobject

Experimental patch, takes into account that many GLib structs have boxes defined by libgobject (mostly in gboxed.c).  This makes these structures much more accessible from typelibs, e.g. it allows using GMainLoop.new() as requested in comment #6.
Comment 14 Pavel Holejsovsky 2010-09-07 17:12:10 UTC
Created attachment 169691 [details] [review]
Make MainLoop and related structures boxed.

Make boxed also GMainContext and GSource.
Comment 15 Colin Walters 2010-09-07 18:25:19 UTC
I've been saying so far that both GLib and GObject are in "may require manual binding" mode, so it's not a bug in GLib that GMainLoop isn't introspectable.

In this specific case, it probably does make sense to box GMainLoop in GObject though.
Comment 16 Pavel Holejsovsky 2010-09-08 13:14:55 UTC
Created attachment 169764 [details] [review]
Make more GLib structures boxed by libgobject.
Comment 17 Pavel Holejsovsky 2010-09-08 13:15:43 UTC
Created attachment 169765 [details] [review]
Recognize GLib structures boxed by libgobject.
Comment 18 Matthias Clasen 2010-09-10 11:09:16 UTC
(In reply to comment #15)
> I've been saying so far that both GLib and GObject are in "may require manual
> binding" mode, so it's not a bug in GLib that GMainLoop isn't introspectable.
> 
> In this specific case, it probably does make sense to box GMainLoop in GObject
> though.

I agree with this sentiment. 

There's no need that every single structure that occurs in glib headers needs to be introspectable. E.g. GIOChannel has been pretty much superseded by gio facilities.
Comment 19 Pavel Holejsovsky 2010-09-13 15:29:13 UTC
(In reply to comment #18)
> There's no need that every single structure that occurs in glib headers needs
> to be introspectable. E.g. GIOChannel has been pretty much superseded by gio
> facilities.

Ok, understood.

> > In this specific case, it probably does make sense to box GMainLoop in GObject
> > though.

But what about GMainLoop/GMainContext? AFAIK these are not superseded by anything else, yet very useful/vital even for higher-language usage/bindings.
Comment 20 Andreas Rottmann 2010-10-04 20:37:57 UTC
(In reply to comment #18)
> (In reply to comment #15)
> > I've been saying so far that both GLib and GObject are in "may require manual
> > binding" mode, so it's not a bug in GLib that GMainLoop isn't introspectable.
> > 

I see where you are coming from, but GMainLoop and GIOChannel were
introspected and usable with previous versions of
gobject-introspection, so I consider this a regression.

> > In this specific case, it probably does make sense to box GMainLoop in GObject
> > though.
> 
> I agree with this sentiment. 
> 
> There's no need that every single structure that occurs in glib headers needs
> to be introspectable. E.g. GIOChannel has been pretty much superseded by gio
> facilities.

It has, but unfortunatly GIO does not provide all functionality
GIOChannel provides.  For instance, it seems not possible to be just
notified (without reading anything) when some GInputStream becomes
readable -- this functionality is provided by g_io_add_watch(), but
there seems to be no equivalent functionality in GIO.

Given that making GIOChannel and the other currently
non-introspectable types work again just requires adding a few boxed
types to gobject, I don't see a reason why this cannot (or should not)
be done.
Comment 21 Pavel Holejsovsky 2010-10-07 11:57:50 UTC
(In reply to comment #20)
> It has, but unfortunatly GIO does not provide all functionality
> GIOChannel provides.  For instance, it seems not possible to be just
> notified (without reading anything) when some GInputStream becomes
> readable -- this functionality is provided by g_io_add_watch(), but
> there seems to be no equivalent functionality in GIO.
> 
> Given that making GIOChannel and the other currently
> non-introspectable types work again just requires adding a few boxed
> types to gobject, I don't see a reason why this cannot (or should not)
> be done.

Actually GIOChannel *is* already boxed by gobject, the problem is that it is not picked up by g-ir-scanner; see my 2nd patch attached to this bug (you'd have to modify it to include only types already boxed by gobject, not the ones boxed by the 1st patch), but I'm not sure if GI maintainers would like this solution ;-)
Comment 22 John Stowers 2011-03-20 05:13:18 UTC
So, to revive this. It looks like these two patches were the resolution for missing introspectable types in GLib.

However, back to the thesis of the bug. Was g-i updated to allow annotation of copy/free functions for structs (without the struct having to be G_DEFINE_BOXED)?
Comment 23 Pavel Holejsovsky 2011-08-31 07:45:06 UTC
Just a note that GMainLoop&co were recently made boxed, and picked up so by GI.  See bug 657725
Comment 24 André Klapper 2015-02-07 17:21:53 UTC
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
Comment 25 GNOME Infrastructure Team 2018-02-08 11:49:13 UTC
-- 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/14.