introspection status

[Colin Walters <walters verbum org>]

Hi,

A quick update on gobject-introspection status is overdue.  The
executive summary is that it's unlikely we can make a hard freeze for
2.32, but on the positive side, a lot of improvements are about to
land in git master, and I'm optimistic that we can do a stable 1.0
around the same time GTK3 will.

== The long version ==

I'm really grateful for all the library and application authors that
have taken the time to use introspection and put up with the build
hassles.  In its use in the shell etc., the concept has definitely
been proven.  However, there were a few serious problems that our
practical experience has revealed.  Given that usage is not yet
widespread, I wanted to take this opportunity to fix things, before
the pressure from the Python porting imposes an API freeze.  So at
GUADEC and since then I've been working on the following (see
https://bugzilla.gnome.org/show_bug.cgi?id=628128 )

First, code quality had suffered immensely over the past ~year as
pretty much everyone working on it jumped in to add a quick
hack/feature/workaround, then got back to their higher level project.

Second, we never really succeeded in our goal of giving C authors good
feedback.  In this topic, the branch is *much* better.  For example:

gtkwindow.h:255: warning: Gtk: gtk_window_get_screen: return value:
Missing (transfer) annotation

Third, which the above line leads me into - the scanner did too much
guessing.  The above warning is actually for the biggest problem I've
encountered in practice, which is the old scanner assuming that
GObject returns were (transfer full), and requiring an annotation if
they weren't.  The problem is that if you forget the (transfer none),
you easily get a mysterious crash later on.  Similarly, our assumption
that an "int *foo" was an out parameter wasn't good.

This will require a fair bit of annotation work to land in the GTK+
stack at least.

Other topics - Zach Goldberg got a great start at GUADEC on a
documentation generator; the exciting bit about this is that we can
generate JavaScript and Python docs interlinked with the C versions at
the same time, which should help C authors and embedders get an
immediate feel for how their API will look. This can land after the
introspection branch.

== API stability ==

This one deserves a topic all on its own.  Introspection is under
quite a bit of pressure here, because on one hand, people want it to
be done so they can get on and write apps.  (And oh man, am I with
them).  Other people keep asking for just one more feature (like a way
to mark a return value as a "success flag" which would then be
omitted), or nested namespaces.

First, I'm fairly confident we can reach .typelib and .gir stability
along with GTK3, so libraries and applications will not need to be
rebuilt for new gobject-introspection.

A more complicated issue is the script API (JS, Python) that's exposed
through the typelib.  I elaborated on this here earlier:

http://mail.gnome.org/archives/desktop-devel-list/2010-June/msg00057.html

So a definite priority is to identify the functions which are
"scannable but suboptimal", like (out caller-allocates).  Other things
we can fill in more gradually.

That's it for now - more if I think of it, or if you think of questions...