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 355352 - If you don't have an instantiatable type for a gtypeinterface, its signals will fail
If you don't have an instantiatable type for a gtypeinterface, its signals wi...
Status: RESOLVED FIXED
Product: gtk-doc
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: 1.9
Assigned To: gtk-doc maintainers
gtk-doc maintainers
Depends on:
Blocks:
 
 
Reported: 2006-09-10 22:51 UTC by Philip Van Hoof
Modified: 2007-09-22 19:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch (782 bytes, patch)
2006-10-11 20:08 UTC, Yeti
committed Details | Review
test case (227.60 KB, application/x-compressed-tar)
2007-08-10 23:35 UTC, Yeti
  Details
test cases (230.04 KB, application/x-compressed-tar)
2007-08-11 08:18 UTC, Yeti
  Details
additional patch (1.05 KB, patch)
2007-08-11 23:02 UTC, Yeti
committed Details | Review

Description Philip Van Hoof 2006-09-10 22:51:59 UTC
The scanner will not find signals if you don't have an instantiatable implementation of a gtypeinterface.

It's the g_signal_list_ids method being used that is causing this bug. Unless a _get_type of an object that implements your gtypeinterface and that *is* instantiatable happened, this function will return 0 signals.

Small example. In the example "tny_account_store_get_type" returns a GTypeInterface's GType. TNY_TYPE_TEST_ACCOUNT_STORE translates to tny_test_account_store_get_type is an implementation of the GTypeInterface TnyAccountStore.

If this test-account-store implementation isn't included in the .types file used by gtk-doc, the signals of TnyAccountStore aren't generated in the documentation.


        g_type_init ();

        gint *signals, nsignals;

/* If you remove this line, signals is 0, else it's 4 in libtinymail */

        g_object_new (TNY_TYPE_TEST_ACCOUNT_STORE, NULL);
        GType type = tny_account_store_get_type ();


        if (G_TYPE_IS_CLASSED (type))
                g_type_class_ref (type);
        g_print ("%s\n", g_type_name (type));
        signals = g_signal_list_ids (type, &nsignals);

        g_print ("%d\n", nsignals);
Comment 1 Yeti 2006-10-11 19:54:51 UTC
The interface's base_init() vtable function -- which creates the signals -- doesn't have any reason to be called until it's actually used as a base of something.  However, the fix should be easy: foo-scan.c must call 

  g_type_default_interface_ref(FOO_TYPE_BAR);

for each interface FooBarIface.  More precisely, it has to call it only for interfaces whose base_init() functions will not be called for other reasons, but calling it for all interfaces cannot do any harm.
Comment 2 Yeti 2006-10-11 20:08:23 UTC
Created attachment 74513 [details] [review]
proposed patch

Reference interfaces in foo-scan.c.
Comment 3 Damon Chaplin 2006-10-13 11:41:37 UTC
The patch seems to work fine (though you missed a semi-colon!).

I've committed it to cvs. Thanks.
Comment 4 Yeti 2007-08-10 23:29:30 UTC
Not fixed entirely.  Or something has changed somewhere in GObject?

If I create a library with only one type, an interface, the inspection fails:

(process:11033): GLib-GObject-WARNING **: gsignal.c:1063: unable to list signals of non instantiatable type `BadgerPesky'

(process:11033): GLib-GObject-CRITICAL **: g_param_spec_pool_list: assertion `pool != NULL' failed

It works if a type that implements this interface is class-referenced before.  Therefore most people don't observe it as libraries typically provide interfaces and some implementations of them.  But if you provide just the interface, you are in trouble.
Comment 5 Yeti 2007-08-10 23:35:50 UTC
Created attachment 93460 [details]
test case

A minimal library (badger) defining only one interface (BadgerPesky).

Unpack, run ./configure --enable-gtk-doc, make.  Observe the errors mentioned in my previous comment.
Comment 6 Yeti 2007-08-11 08:18:30 UTC
Created attachment 93476 [details]
test cases

The problem is only with inspection of interfaces that do *not* register any signals.  If their base init function actually registers some signals, it is sufficient to call

    g_type_default_interface_ref(itype);

and signal inspection works.  But if they don't it breaks.

Attached a test case of both: for reference added BadgerDomestic interface which (unlike BadgerPesky) registers a signal and therefore works.
Comment 7 Yeti 2007-08-11 09:36:36 UTC
Unfortunately the test cases do not Just Work as gtk-doc distributes too many built files for that by default.  See GObject bug 465625 and bug 465631 for better test cases (not involving gtk-doc, just performing the inspection).  It seems this is a GLib issue and gtk-doc cannot do anything (more) about it.
Comment 8 Yeti 2007-08-11 23:02:44 UTC
Created attachment 93520 [details] [review]
additional patch

We can do something.  The default initialization function can do

g_type_class_ref(G_TYPE_OBJECT);

in addition to g_type_init().

This ensures GObject is initialized (and consequently property pool is created) and something with signals ("notify") was initialized (and consequently g_signal_list_ids() finds nonzero n_nodes).
Comment 9 Stefan Sauer (gstreamer, gtkdoc dev) 2007-08-12 09:05:30 UTC
Too bad that this way its goona be hard for people to figure out that they should eventualy add this too.

2007-08-12  Stefan Kost  <ensonic@users.sf.net>

	patch by: David Nečas <yeti@physics.muni.cz>

	* gtkdoc-scangobj.in:
	  Make introspection of interfaces work in more cases. Fixes #355352.