JUL
14
2011
|
Gtk Hello World in Qt C++Recently I've been working on the smoke-gobject bindings in the evenings and weekends. Although I'm working on other things for my job at Codethink during the day, I'm sufficiently excited about these bindings to be unable to stop spending my free time on them. This is at the expense of working on the new version 3.0 of QtRuby sadly. I'll try to explain on this blog why I think the Smoke/GObject bindings will be important for the parties attending the forthcoming Desktop Summit to consider, and why I'm giving them a higher priority than Ruby. As the title of the blog suggests I've just got a Gtk Hello World working, written in Qt. Here is the code:
You can compare the Gtk C equivalent example code in this Getting Started Gtk tutorial. I could spend lots of space explaining what it is all about, but anyone familiar with Qt programming ought to be able to understand the code without any explanation - that is the clever thing in fact! This demonstrates that an auto-generated binding for GObject libraries described by GObject Introspection .gir files can seamlessly inter-operate with Qt libraries. And it looks much the same as a native Qt library to a Qt programmer. Normally a language binding for Gtk that allows you to write an app to show a hello world button is a fine thing. But those normal language bindings don't mean that you have united two of the major Linux desktop communities, they just mean that you can write Gtk programs in the language of your choice. So to me, this latest binding is different in kind; it is an opportunity to integrate both libraries and communities, and it isn't limited to being able to program Gtk in your latest nifty language. I'm going to the GObject Introspection Hackfest in Berlin, which should allow us to nail down the technical details and get close to bringing the Smoke Gobject bindings up to production quality. It will also be about the social side of linking the two communities in conjunction with the technical discussions. The Smoke GObject apis are described with QMetaObjects, and that means that the apis will 'just work' with QML. I am looking forward to trying out Clutter programming in QML soon, as I believe that should be possible. That shows that these bindings are not just about C++ programming, but languages like QML and QtScript that are driven by QMetaObject introspection too. You can get the latest version of the gobject-smoke bindings from the Smoke GObject Launchpad project. See the README file for an explanation of what to do with them. |
![]() |
Comments
Wow, that is impressive. Do
Wow, that is impressive.
Do you actually generate smoke libraries (or a Smoke interface, rather. The data for the library is already provided by GObject introspection I guess) for the bindings, or only Qt interfaces?
Having the Smoke interface (as in smoke.h) for every library would make actual language bindings development even easier!
Re: Smoke libraries
Although the project is called 'smoke something' it doesn't actually use the smoke libraries. I called it 'Smoke GObject' so that it would sound like it was part of the 'Smoke bindings'.
Going the other way, and wrapping Qt C++ libraries so that they looked like GObject Introspection libraries we couldn't use QMetaObjects as they are not powerful to describe complete Qt apis with multiple inheritance and so on (that is why we have Smoke). So if we were to go the other way we would have to use Smoke and then it would make sense to call the whole project 'Smoke something' and that would be technically accurate.
So the Smoke in the name is more about 'marketing' and 'brand recognition' or something like that, where the name Smoke comes to be an umbrella term for a family of language bindings technologies.
Instead of generating Smoke libraries the Smoke GObject runtime is all done with QMetaObjects as they are powerful enough to describe the GObject apis pretty much.
The QMetaObjects are all generated at runtime from the GObject Introspection data, and some of the GI data is saved in tables to make it easy to look up from the corresponding QMetaObject data. That would be sufficient to provide a runtime for a dynamic lanaguage like QML or QtScript, which work by introspecting QMetaObject data. There is a small runtime that then sits in between the dynamic QMetaObjects and the GObject Introspection layer to convert signal, slot, constructor, enum and property calls so that they look just like normal Qt ones.
The C++ code for the C++ bindings is generated statically. The first step of the code generation is to generate the QMetaObjects as for use with dynamic languages. The QMetaObject data is then read and used to generate most of the code. Some help is needed to get extra data out of GObject Introspection, but the bulk of it is pretty much a dump of what is in the QMetaObjects.
I haven't decided on how to name the headers and where to install them yet. At the moment there is just '#include "gtk_button.h"' or '#include "glib.h"' in the code which could clash with existing headers gobject headers. So one possibility would be to always have a longer path with 'smoke' in it, such as '#include <smoke/gtk/button.h>'. If there were Qt based and GObject based libraries that had the same names, then that scheme could cause us problems, but I'm pretty sure there aren't any such clashes.