There is one single thing that is, in my opinion, generating a fair amount of hype and reinvigorated interest in the GNOME platform: GObject-Introspection (or “GI” to save some typing 
). In short, it works like this:
- Library developers add annotations to the documentation comments of functions.
- The GI support tools generate XML and compiled API metadata.
- You have a library to use that metadata at runtime.
The last thing is very interesting, especially the runtime usage of metadata… because it enables dynamic language bindings. This means that developers no longer have to build e.g. the Python bindings for themselves but just annotating the source code! (Side note, they already exist as PyGI PyGObject.) A direct implication of this is that there is a single “glue module” for your favourite language, and that all GI-capable libraries are available without having to build any code. To make it clear, let me put it this way:
Definitely GI is somewhat that makes the platform even more awesome than before, because it will allow for having support for more languages to be used to write GNOME applications, and also bindings will not lag behind the libraries.
Being so awesome, I wanted to try it out. It has been some time since I do not use Lua, so I thought it would be interesting to write a GI glue code for Lua, provided that writing extensions using its C API is dead simple. This way LuiGI was born and I invested about a total of eight hours to write ~1300 lines of code which allow for using some GI-aware libraries. The mandatory screenshot:
The above application window was created entirely from Lua, with LuiGI using libgirepository to dynamically find functions, classes and methods at runtime, using the following script (I especially like how the Lua syntactic sugar for function calls on tables makes setting properties at instantiation time look):
local Gtk = require ("gi").Gtk
Gtk.init (0, nil)
window = Gtk.Window { title = "Toolbared window",
default_width = 400,
default_height = 300,
allow_shrink = false }
sbar = Gtk.Statusbar { has_resize_grip = true }
toolbar = Gtk.Toolbar { tooltips = true }
vbox = Gtk.VBox {}
sbar_ctx = sbar:get_context_id ("default")
sbar:push (sbar_ctx, "Look ma, this was set from Lua!")
toolbar:insert (Gtk.ToolButton { stock_id = "gtk-quit" }, -1)
toolbar:insert (Gtk.ToolButton { stock_id = "gtk-about" }, -1)
vbox:pack_start (toolbar, false, false, 0)
vbox:pack_start (Gtk.Label { label = "Empty area" }, true, true, 0)
vbox:pack_end (sbar, false, false, 0)
window:add (vbox)
window:show_all ()
Gtk.main ()
Note that there is no event handling at all in the above code. The reason is that I have not yet implemented support for using Lua functions as callbacks 
What I think about GI after getting my hands dirty —by writing a bind, no less— is that the Batman image above is perfectly well-grounded. The code needed to glue GI support into some language is not trivial, but I still think the API is quite convenient provided that it deals with a rather complicated issue without breaking any existing GObject-based code. The part I have found harder so far is handling conversion of values between the Lua and C worlds.
Today I was hacking a bit more on LuiGI, and dropped by the #introspection IRC channel, precisely to ask a couple of questions about how to get some information for type conversion, and the kind people there made me note about LGI, which is also a dynamic GI binding for Lua. I have not been able of testing it because it needs a bleeding edge libgirepository, but looking at its code I can tell that it is more complete than my own, so I will be probably contributing to it instead of duplicating efforts.
Some final words: I am truly convinced that GI does not only looks good, but it is actually very good. I foresee that this gust of fresh wind will bring more awesomeness to GNOME 
Hi,
I’ve been playing with GI in Grilo and I agree: it’s awesome!! Just one little thing: PyGI is deprecated, and has been merged into PyGObject.
You’re right, I knew about the merge of PyGI in PyGobject, but my lazy mind tricked me and decide that it would be better to write PyGI…
I did a quick edit to the post, thanks for noticing the typo.
That’s very interesting!
I would like to see a Lua example using Grilo to show Youtube content. It would be great both for Grilo and Lua
I will be happy of taking a look at doing some basic example with Grilo and Lua, but I need at this moment to build libgirepository from the lastest Git sources (it has some new useful stuff). The same goes for Grilo, to have good GI support. By the way, that would deserve a new post, I guess
Building it inside jhbuild works OK, and you’d just need to build gobject-introspection (and its dependencies) and grilo & grilo-plugins (I mean: not the whole gnome-3 module set)
Your feedback with Grilo’s introspection would be really appreciated, as currently we’re just focusing on Python and JavaScript support. Maybe some design choices would benefit working from Lua (or other languages we haven’t explored yet).
And sure: that would deserve a new post
Awesome hack!