Re: GObject introspection support

["Juan A. Suarez Romero" <jasuarez igalia com>]

On Wed, 2010-07-21 at 23:20 +0200, Simón Pena wrote:
> *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.

I think it is the best approach, indeed. I suggest to change definitions
by inline functions after next release.

> 
> *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.
> 

Yeah, actually there are two approaches:

  * Removing those extern variables and just use the functions as
explained in [3].
  * Keep the extern variables, but do not "introspect" them. Thus,
applications using introspection would need to use the above functions,
while C linked applications can still use these externs. Not sure if
this is possible or not.


> *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.
> 

Pretty sure this is a ugly hack. So I understand the problem is in
GParamSpec, not in Javascript, right?

Not sure which introspection/glib version are you using, but it would be
good to know if this still happens with upstream introspection/glib. If
so and it is actually a bug in glib, then I think the best is to wait
for a fix (or just proposing one ;)) in glib.


> *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.
> 

I think we need to review our code to be sure what approach fits better.


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

Good!

> *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?
> 

Well done.

IMHO, the best way would be creating an 'introspection' branch where to
upload all the changes you're doing, so anyone can take a look at them.

And then someone can cherry-pick appropriate commits and put them in
master.

	J.A.