Re: gobject introspection

["Michael Lawrence" <lawremi iastate edu>]

On 5/1/07, Rob Taylor <rob taylor codethink co uk> wrote:

Michael Lawrence wrote:
> On 5/1/07, Havoc Pennington <hp redhat com> wrote:
>>
>> Hi,
>>
>> Michael Lawrence wrote:
>> > I am wondering what is happening with GObject introspection. It seems
>> > that it has been in the works for some time now but that development
>> has
>> > stalled.
>>
>> Rob Taylor started working on it again, see
>> http://bugzilla.gnome.org/show_bug.cgi?id=363228
>
>
> Ok thanks for pointing that out.
> The original bug is here:
> http://bugzilla.gnome.org/show_bug.cgi?id=139486

Hmm, I'll try and link all these together in some sensible dependancy.

>> 1) What are the overall goals of the project? From what I gather the
>> > goals are twofold:
>> >   a) To define a common representation (GIDL) for GObject-based API's.
>> > Binding generators can then be ported to use a standard format rather
>> > than the current assortment of defs files, GAPI, etc.
>> >   b) To support run-time introspection by accessing a binary blob of
>> > metadata.
>>
>> Combining a) and b) I would say part of the goal is run-time binding
>> generation, i.e. right now most of the bindings involve a couple megs of
>> static function stubs, ideally this could be replaced with perhaps a
>> couple hundred K of generic code that built binding objects on demand
>> (much as e.g. dbus-python works)
>
>
> My thoughts as well.

Ditto :)

>> 2) How is the GIDL/metadata generated? The Vala project has some scripts
>> > that generate GIDL from header files. This is obviously a difficult
>> > task, because things like memory management, in/out parameters, etc
>> > cannot be automatically derived from header files. Thus, human
>> > annotation is necessary.
>>
>> My preference is this pipeline:
>>   - Scan headers (or code in other language) and generate a base IDL
>>     file (or in-memory parse tree)
>>   - Allow "magic comments" in the headers to modify the IDL that would
>>     otherwise have been created. Similar to gtk-doc comments.
>
>
> I made some suggestions along those lines a while ago on the GtkDocFuture
> page: http://live.gnome.org/DocumentationProject/GtkDocFuture. It's at the
> bottom of the page.

Yeah, hmm, my take is that the introspection data should live in the
code, and gtk-doc should pick these up for the docs (just like signals
and object hierarchy). I'll be able to tell more after hashing out my
prototype.

I'm thinking that gtk-doc-like markup may be a more convenient way to express some of the metadata. There is already too much code required to create a GObject class. Then again, meta-languages like Vala would take care of this stuff behind the scenes anyway. I'll wait to see your prototype.

One point I'm interested in from that POV: are there any
plans for gtk-doc to document signals/properties on interfaces? ( e.g. by
instantiating objects pretending to implement them?)


> Michael
>
>  - Allow a "merge file," a lookaside IDL file that overrides or adds to
>>     the scanned IDL - similar to magic comments but not in the C code
>>     itself
>>   - Output (or keep in-memory parse tree, as appropriate) the resulting
>>     IDL
>>   - Output a binary type lib containing the same information
>>
>> A pipeline should also be possible where you write the IDL file first
>> and then a C header is generated. This is useful when the IDL file is
>> part of a spec or shared between multiple apps.
>>

I really don't want force people not coding dbus applications down this
path of IDL-driven development.

Some sort of interface description is required for language bindings as well, which means this applies to pretty much every GObject-based library.

I'm aiming to get introspection such
that, if need be, you could code it by hand but have some useful tools
and macros to help make life easier.

The current plan for dbus-glib is to have a tool that generates
introspectable GInterfaces from annotated xml (or dbus-doc xml and a
separate glib type annotation). The provider object would implement the
Ginterface, the remote end could then be a factory-produced object
implementing the GInterfaces corresponding to the dbus interfaces on the
object. Again, we seem to be discussing dbus-glib issues in the wrong
forum, so I've cc'd in the dbus mailing list.

Thanks,
Rob Taylor