Re: New feature for GTK+

[Johan Dahlin <jdahlin async com br>]

[adding gtk-devel on CC]

Ryan Miller wrote:
> I checked out the GObject introspection site.  The goals are very 
> similar, yet the programming workflow is different.
>
> As I see, the GObject-introspection workflow would be something like:
> GTK+ dev compilation-> C->GIR header file generation script -> 
> re-generation of GIR to Python lib -> compilation of Python lib -> done

This is one of the flows; Check out Havoc's mail for a better explanation:
http://mail.gnome.org/archives/gtk-devel-list/2008-June/msg00006.html

> My proposed architecture simplifies the workflow to something like:
> GTK+ dev compilation and automatic generation of run-time binding info 
> -> done

This is similar to the typelib we want to have.

> The simplifications are a result of the following differences:
>  - there is no C parser needed (generators based on C are quite 
> difficult when #define/#include are used)

The parsing of C headers/sources is a pragmatic one, it's thought
of a way to bootstrap this effort.

A proposal is to start using IDL's inside the libraries themselves
to define the API and then generate code and introspection information
from the IDL.

Your proposal is not really practical, it's not just gtk+ that needs
to be annotated but at least another 50 libraries used in the GNOME stack.
As a maintainer of a library I would not want to add all this redundant 
information to my headers, you quickly end up with headers like
popt or librpm. It has been discussed in the past and deemed impractical.

>  - the generation of run-time binding info is done by gcc and not 
> another build step
>  - the call interface is very simplistic.
>      > msole uses a many functions/interfaces approach which is meant to 
> support network-based remote access to objects and many different kinds 
> of C development/threading styles.  Furthermore, it is a cumbersome 
> programming experience and isn't as popular as when it was first created.
>      > my architecture uses three methods:
>      > invoke(functionname,...) - to call a function
>      > querycall(functioname) - to return call information
>      > info(predicate) - to search for functions/structures

Have you checked out the libgirepository C library?
The same api is also used by a couple of other bindings (perl,js).

The proposed api is not enough to write completely dynamic bindings.
I have written a python prototype called pybank, you can see there what kind 
of introspection metadata is actually required on the python side of things.

> I believe the development cycle for creation of another GTK+ language 
> binding would be greater with a GObject-introspection approach.  The 
> other concern you may be interested in is the ongoing work from changes 
> to the C->GIR generator brought on by additional data-structures that 
> require additional GIR generated code(?) to create structures to 
> directly bind functions (since compile time inspection can not decode 
> allocation schemes).  In addition, there will be work when macro/include 
> based C coding styles break the generator.  Additional data-structures 
> in my approach would require a GTK+ C function to convert from a GObject 
> to a custom data-structure and any necessary code to handle when a 
> function modifies parameters.

We're using a complete bison/lex based C parser which so far has been
able to parse the whole stack, it is different from earlier header parsers 
and it will not break if you change the coding style of the headers.

Part of older discussion for gtk-devel archiving:
>
> On Mon, Jun 2, 2008 at 5:29 AM, Johan Dahlin <jdahlin async com br
> <mailto:jdahlin async com br>> wrote:
>
>     Hi Ryan
>
>             I'm a software developer that has a partial implementation
>             of an idea for
>             GTK+.  I started looking at the GObject code to make a TCL
>             UI binding
>             package.  I saw that there was introspection for properties
>             and liked the
>             general reference counting and class like structure.  What I
>             saw missing was
>             the ability to call function in the objects at runtime like
>             one could
>             do with the object properties.
>
>
>     The idea is to add a typelib similar to xpcom/msole which would
>     expose enough information to make it possible to call (method names,
>     parameters,
>     ownership transfer etc).
>
>
>             in the gbase64.h header file, conceptually there is a
>             function declation
>             like:
>              guint g_base64_encode( gchar *pIn, gint nLen)
>
>             this would be translated to:
>             GOBJECT_METHOD(guint,g_base64,encode,(gchar *pIn, gint nLen))
>
>
>     The approach we take is to parse the headers using a C parser, which
>     can extract all that information without the need to modify all the
>     exported headers.
>
>     For information which are not available in the headers, such as
>     default parameter values, ownership transfers (should I free the
>     return value after I used it?), will probably be added as gtk-doc
>     annotations.
>
>     To find out more about the GObject-Introspection project, please check
>     the mail Richard mentioned above.
>
>     Johan
>
>