Re: GObject introspection support

[Simón Pena <spenap gmail com>]

On 22/07/10 14:47, Juan A. Suarez Romero wrote:
> 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.

Done. I checked [1], and picked the approach consisting on declaring
those functions as "extern", and defining them as "inline". That way,
according to that source, "the program behaves the same as if you had
not used the inline keyword, except for its speed."

I have these changes ready, will send them later.

[...]
>> 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.

The second approach is the one we're following right now: as
introspection doesn't handle those predefined keys, applications using
it need to rely on the above functions. So no need to change things.

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

No, the problem is in JS. PyGI seems to work fine with GParamSpec (will
elaborate more on that), while JS doesn't know how to handle that data type.

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

Finally I got jhbuild working, so I tested upstream introspection and
glib. Haven't tested upstream gjs: I'm on my way.

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

With jhbuild working, I then tried to replicate JS test from python
using PYGI, with mixed results: everything works (invoking Grl.init,
getting the either the ParamSpecs or uints for the metadata keys and all
that). Callbacks work, too.

However, there's something broken there (not related to introspection,
I'm afraid, but grilo in general, or its dependencies). When I do a
search, either from JS or Python, no results appeared. I then tried to
use the GTU test provided, and the logs said:

(lt-grilo-test-ui:18408): test-ui-CRITICAL **: Error: Failed to connect
Jamendo: 'Operación no soportada'

I searched for that error in the Jamendo plugin: it's on the
read_done_cb, and, from the code, looks like it's a vfs error. Do you
know what it could be?

Keep enjoying the GUADEC, cheers!

[1] http://gcc.gnu.org/onlinedocs/gcc/Inline.html