Re: GObject introspection support

[Simón Pena <spenap gmail com>]

Hi,

This is a follow up to the previous emails about GObject Introspection
support ([1] and [2]), with the goal of summarizing those issues I've
been finding during these days.

*ALIAS:*

The first thing was related to the g-ir-scanner ignoring defined alias,
like

#define grl_config_set_api_key(config, key)    \
  grl_config_set_string(GRL_CONFIG((config)),  \
                       GRL_CONFIG_KEY_APIKEY,  \
                       (key))

The approach I followed to get those alias working was defining actual
functions, preserving the same API.

*NON-NUMERIC, NON-STRING CONSTANTS*

The second one was related to metadata keys, like

extern GrlKeyID GRL_METADATA_KEY_ALBUM;

Currently, the gobject-introspection mechanism is able to deal with
numeric and string constants, like

#define GRL_CONFIG_KEY_PLUGIN      "target-plugin"

But doesn't know how to deal with other data types (in this case,
GrlKeyID, which is a pointer to a GParamSpec struct). As we have two
functions,

grl_plugin_registry_lookup_metadata_key -to retrieve a key given its name

grl_plugin_registry_get_metadata_keys -to retrieve all keys

we don't really need the constant support to access the keys. Juan, in
[3], also said that they can be removed, so this isn't a big gir concern.

*GParamSpec and GError:*

Although they are supported in gir, we have problems using them from
GJS. In the GParamSpec case, we get the following error:

"Error: Can't create a Javascript object for ParamSpec; no
way to copy". The type isn't supported yet.

In the GError case, the error is "Unhandled type error converting
GArgument to JavaScript", and it's already reported in [4]. It has to do
with the error being an 'in' param, and the bug report states how an API
could be done to be more introspection friendly with regards to GErrors.

The way I managed to workaround this, as Edu suggested, was tagging
those types, both GParamSpec and GError, as uints. This way gjs is able
to handle them. This is a temporary fix, and could introduce bugs in
architectures where uints and pointers aren't the same size. Another
tag, "any", should work (it is a 'pointer to anything' [5], search for
'any'), but isn't implemented in GJS, too.

*CALLBACKS*

GObject Introspection currently provides three different scopes for
callbacks: "call", "async" and "notified"[5] (search for callbacks).
Other possible scopes are discussed at [6].

They differ in the way they handle the resources needed for the
callback, including the closures. Using the scope "notified" lets us do
the calls. However, I'm not yet sure about the implications it has.

*PYGI*

I'm currently trying to get jhbuild to build pygi, so I can test how
well work these bindings within python introspection.

*CHANGES*

Some of the changes I introduced are stable/fine (like replacing
#defines with functions or filling missing tags and documentation).
Others are more 'experimental', like using 'uint' to tag those types not
implemented in gjs. So maybe we could (after the release scheduled for
this week is done) submit those stable changes to the master branch, and
create and alternate other for the experimental ones. What do you think?

[1] http://mail.gnome.org/archives/grilo-list/2010-July/msg00067.html
[2] http://mail.gnome.org/archives/grilo-list/2010-July/msg00120.html
[3] http://mail.gnome.org/archives/grilo-list/2010-July/msg00175.html
[4] https://bugzilla.gnome.org/show_bug.cgi?id=618193
[5] http://live.gnome.org/GObjectIntrospection/Annotations
[6] https://bugzilla.gnome.org/show_bug.cgi?id=556489

BR,

Simon