On Thu, Aug 26, 2010 at 1:17 PM, Havoc Pennington <h...@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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
