Re: [GObjectIntrospection] Cleaning up GIRepository

[Johan Dahlin <johan gnome org>]

On Thu, Aug 26, 2010 at 1:17 PM, Havoc Pennington <hp pobox com> wrote:
> It might be worth thinking about a gradual path to first allowing new
> code to be written with only code to create static typelibs (runtime
> registration stuff would be autogenerated), and then in glib/gtk 4.x,
> the idea would be to drop the runtime-registration-based introspection
> features from GType.
>
> I guess roughly speaking, the idea would be that you have magic
> comments or xml or macros or ???, and from that g-i tools make a
> typelib, and then there's some way to autocreate the g_signal_new,
> g_object_install_property, etc. from there. Who knows.

We've talked about that during the gtk+ hackfest in berlin 2008.
Tim uses as similar technique in Beast where he specifies classes
with parameters in an IDL file and it then generates a lot of metadata which
is compiled into the library, example:
http://git.gnome.org/browse/beast/tree/plugins/davbassfilter.idl
http://git.gnome.org/browse/beast/tree/plugins/davbassfilter.cc

I using a interface description language such as IDL is the right solution
for solving this within gtk+ etc.

To put this in context of gtk+, it would mean:
GTypes would be specified in an idl, they would also contain:
* implemented interfaces
* properties
* signals
* bindings
* methods
* settings
* virtual methods
* introspection annotations

The IDL would be used to generate:
* source class: init, class init, set property, get property and
  getters and setters, constructor(s)
* header: everything
* gir: everything

The rest of the actual class logic would be in an overridden file
which is used as input by the idl compiler when source/header classes
are generated.

Of course, this would have to be accepted by the gtk+/library maintainers.
-- 
Johan Dahlin