Re: GIntrospection and poppler

[Matthias Clasen <mclasen redhat com>]

On Wed, 2005-05-04 at 03:11 -0400, Jonathan Blandford wrote:
> Hi,
> 
> I had a look at the GIntrospection work Matthias had done at
> http://bugzilla.gnome.org/show_bug.cgi?id=139486 
> 
> I wanted to try to convert poppler-glib over to use this system.  It is
> a fairly small library, with two GObjects, a couple boxed types, and a
> bunch of enums.  

Thanks for doing this experiment, Jonathan.

> I wrote up an quick gidl file which appears to do ... something.  I'm
> not 100% sure how to interpret the output yet, and will have to play
> with that more later.  I'm posting the xml file to this list in case
> anyone else wants to try it on real code.
> 
> Here are some issues I had:
> 
>  * I needed a constructor for boxed types.  I put a patch in bugzilla to
>    add support for this.  Also, return-types in constructors seem to be
>    optional.  They should prolly be mandatory.

agreed

>  * I didn't bother with any of the copy/free functions that go with
>    boxed types, as g_boxed_copy/free will work as well.  Does this make
>    sense?  Seems like something we can't automate.

Not sure if having copy/free specified buys us anything.

>  * There was no way to indicate const arguments.  I don't know if it's
>    important yet to indicate that some functions modify their input
>    while others don't, but it seems like it will be.

I think in/out/inout allow you to specify this. If a parameter is const,
it has to be in. If the function modifies a parameter, it has to 
be inout.

>  * I had to put <return-type type="void" /> in all functions without a
>    return value.  Might be nicer to make this field optional.

maybe.

>  * There's no way to indicate a union.  I suppose I can add a bunch of
>    accessor's, but it's pretty obnoxious.  It'll be worse for GdkEvent,
>    too.

ok, so we probably need unions

>  * I couldn't indicate what the contents of a GList are.  I vaguely
>    recall this went by in the last round of mail, but I don't see it in
>    the archives off-hand.  This is a must.

I'm a bit unhappy with how this is currently done, but the parser allows
you to specify types like GList<GtkWidget>, GHashTable<string,GObject>
or GError<GMarkupError,GFileError,GdkPixbufError>

> 
>  * I was confused by the relationship between namespace and name.  Eg,
>    should I be doing:
> 
>   <namespace name="Poppler">
>     <object name="Page" ...
> 
>   or 
> 
>   <namespace name="Poppler">
>     <object name="Poppler.Page" ...
> 
>   I did the former, but it seems like some of the examples do the
>   latter.  When I refer to a type in the same module (such as in a
>   parameter or return-type), do I need the explicit namespace?  Or can I
>   just do eg: <return-type type="Page" />.

Currently, the lookup is done in all available namespaces, based only on
the name. Ie if you refer to a type named "Foo", we look for "Foo" in
all available namespaces. We should probably make it possible to
explicitly refer to a type in a different namespace, eg. using
"FooLib::Foo". Some of the examples use qualified names like
"FooLib.Foo" to achieve the same effect, but it would certainly be
better to lift this from a naming convention to something that can be
enforced.

>  * It seems like we can be more sophisticated with GError.

See above for how to specify allowed error domains.

>  * How does it know where in the struct the various fields are?  Or do I
>    need to layout the whole struct when defining fields?

The binary metadata format has "struct_offset" for fields and vfuncs,
but the code doesn't handle that yet.

>  * Finally, I couldn't specify a parent class for objects outside of the
>    library (eg, a GObject.GObject).  Tnis seemed to not cause any
>    trouble for GdkPixbuf in a return value, but caused it complain when
>    the 'parent' attribute was set.
> 

I'll check that.

Matthias