>Disclaimer! First of all – this is not an attack on any toolkit, nor critique. Rather, it is a hacker sitting down and trying out an idea.
It has been a couple of years since I first tried out this idea (some seven, I believe). This time, licensing permits it and I believe that the timing is right. So, without further ado, let me introduce GTK+ made Qt.
Qt and GTK+, and all other toolkits out there, provide more or less the same functionality (take that with a grain of salt, but the core is true). So, my idea was to wrap Qt in a GTK+ API layer. Just to see if it could be done. Attacking the problem at this level might be considered stupid – but I like to get results fairly quickly, and this way I can work with GTK+ code directly, instead of writing a ton of underlaying code just to get something to compile.
There are tons and tons of corner cases and not so corner-ish cases that can make this break. The implementation is miles and miles from perfect and the code I’ve been testing it on is rather trivial. What I’ve done is that I’ve taken one of the examples of the GTK+ 2.0 Tutorial and made it do what it is supposed to do (sort of). Examples of what I’ve ignored in the process:
- Event handling functions get NULL instead of a GdkEvent pointer.
- Packing flags (e.g. homogenus and spacing when calling gtk_hbox_new) ignored – I simply use QVBoxLayout, QHBoxLayout and QGridLayout where they fit best.
- Only a minimalist part of the API has been implemented (the process is build, add missing symbols, repeat)
- Most GtkXxx classes are defined to a QWidget. Objects are casted up and down all over the place to work around this.
However, the problem isn’t really matching the APIs to each other and getting every pixel right. At least, that is not the current problem. Instead, matching Qt’s C++ style OO to GTK+’s is the problem. What are the differences? I hear you ask.
To create a trivial dialog in Qt, you inherit the QDialog class and then create the children in the constructor of your new class. In GTK+, you generally create a function for creating the dialog in question. In that function, all widgets (including the dialog) are created and put in a proper hierarchy. The resulting hierarchy of widgets is (95%) identical, and all the custom code to make it tick is there – it is just placed differently in the source.
Another difference that has a large impact is the fact that Qt event handles are virtual methods of QObjects and slots are QObject methods. In GTK+, they are plain C functions that are passed as function pointer to g_signal_connect calls.
So, the starting point is this example. I’ve placed that code in helloworld.cpp (we need it to build as a C++ source file, I’m sure that GCC can be convinced of that by other means, e.g. by using g++ directly, but just changing the extension does it for me).
The only change made to the source code itself is that the include of gtk/gtk.h has been replaced by the inclusion of gtk-made-qt.h (no, the name is not critique, it is just my strange humor). The header file is the container of the rest of this experiment.
The GTK+ Hello World example running in QtCreator on Windows Vista
First of all, I’ve made some rather rude typedefs and defines with regard to GLib (this just shows how much that needs to be redone to do this properly):
#define G_OBJECT(obj) ((QObject*)(obj))
#define G_CALLBACK(func) ((void*)(func))
typedef void* gpointer;
typedef bool gboolean;
typedef char gchar;
#define g_print qDebug
...
There is more of this of course, and some of it is spread out across multiple header files. Next follows the same horrific crime, but this time made to some of the GTK+ widgets:
#define GtkWidget QWidget
void gtk_widget_show(QWidget *w) { w->show(); }
#define GTK_WINDOW_TOPLEVEL (0)
QWidget *gtk_window_new(int) { return new QWidget(); }
void gtk_window_set_title(GtkWindow *w, const char *t) { w->setWindowTitle(QString(t)); }
...
#define GTK_BOX(obj) (obj->layout())
void gtk_box_pack_start(QLayout *l, QWidget *w, bool expand, bool fill, int padding) { l->addWidget(w); }
As you can see, straight forward, brute force, get the job done hacks. All this shows how close the different APIs match. This is trivial code (albeit unsafe) and adds almost no extra conversions or checks.
The really interesting part is the implementation of the g_signal_connect function. Here, bridges for both events and signals/slots are dynamically setup. So, here it is in all its glory:
void g_signal_connect(QObject *src, const char *cstrEventName, void *f, void *data)
{
QString eventName = QString(cstrEventName);
if (eventName.endsWith("_event"))
{ // This is an event, f is an eventFuncPtr
QObject *o = QGtkEventFilter::createFilter(eventName, eventFuncPtr(f), data);
if(o)
src->installEventFilter(o);
else
qWarning("Failed to match GTK event '%s' to a Qt event filter.", cstrEventName);
}
else
{ // This is a callback, f is an callbackFuncPtr
QObject *o = new QGtkCallbackBridge(src, callbackFuncPtr(f), data);
const char *signalName = 0;
if(eventName == "clicked")
signalName = SIGNAL(clicked());
if (signalName)
QObject::connect(src, signalName, o, SLOT(trigger()));
else
qWarning("Failed to match GTK signal '%s' to a Qt signal.", cstrEventName);
}
}
To my surprise, that is all that it takes. The QGtkCallbackBridge is a trivial QObject that calls the given function pointer with the QObject::sender() and the given data pointer when signalled. The QGtkEventFilter is not much more complicated. It simply filters out the event in question and triggers the given function pointer in much the same way. I’ve created a factory for the event filters, as I want them to re-create something looking like the original GdkEvent structure. There is actually one event filter class for each type of event, just so that this code can be added.
Well, I’ve not packaged the code yet. My goal is to try at least one more example first (perhaps two, given time). In the mean time, let’s see if this can be made useful (a large enough portion of the GTK+ API needs to be implemented for that) – and if the idea is interesting at all (from a political standpoint, etc). As it stands now, this might help porting GTK+ applications to Qt only platforms, or it could be used as a migration kit (not that I encourage people to migrate from GTK+ to Qt – it is a choice that every developer has to make – use whatever feels comfortable to you).
