Author: Johan Thelin

I’m working on a presentation on getting started with Qt. For it, I need package names for Qt for different distros. E.g. (k)ubuntu: qt-sdk, debian: qtcreator. What package installs QtCreator + Qt and needed tools for your distro? Please comment!

Thank you!

The last week, I sadly missed foss-sthlm, due to snow. Apparently Swedish trains are built for the summer, so I hope that there will be another get-together later this spring.

I’ve also been working hard on my embedded Linux course. The course date is kind of tight on the Easter, but hopefully STF can find a nice crowd to work with.

Finally, I’ve been spending time trying to learn QtQuick (QML, Declarative UI). I’m really enjoying Jürgen’s blog on this, as the approach feels new to me.

Wrapping Qt in GTK might seem like an impossible task, but the fact is that both toolkits, in turn, wrap the same APIs themselves. So, how does the progress look this far?

The first example, upgraded hello world, works like a charm and does what is expected. There is only one change that has to be made to the example, and the need for it will go away when I’ve started cleaning the code.

Changes made to the example:

• Replaced the gtk/gtk.h headerfile with my substitute.

The next example, table packing, simply demonstrates the grid layout abilities of GTK. There seems to be a couple of pixels between the rows for some reason (I will investigate at a later point), but apart from that, everything works. The changes made are the same as for the first example.

Robin Burchell (w00t) has attempted something similar in the gqt project (gitorious link). We will discuss how we can join forces ASAP (I’ve been sort of unavailable this weekend). The gqt project has clean code – look great. It employs a different approach than I when it comes to mapping signals/slots/events and for handling the construction of menus.

Another benefit of doing the manual menu example was that I had to have a better look at the events mechanism. As it seems, the “event” signal hooks into all events (like a Qt event filter). This means that there has to be a general event filter, as well as specific event filters (for when connecting to a specific event such as “delete_event”). This kind of breaks my idea of splitting out the code for creating a specific GdkEvent for each type of event in a separate class, so I need to think a bit about that (shouldn’t really be a major issue – I just don’t want code duplication).

Back to the menu widget versus action approach. As it seems, the QAction and QWidget classes’ common base is the QObject class. Thus all pointers to GtkWidget, GtkWindow, etc. needs to be pointers to QObject. That way, the menu object can be made to match quite nicely. The downside is that the code already contained quite a lot of casts. Now it has even more. For instance, a trivial function such as gtk_container_set_border_width needs casting:

void gtk_container_set_border_width(QObject *o_w, int spacing)
{
   QT_WIDGET_ASSERT(w)w->setContentsMargins(spacing,spacing,spacing,spacing);
}

The QT_WIDGET_ASSERT macro creates a QWidget pointer named w, by casting o_w using qobject_cast and then asserts that the pointer isn’t null. I’m not sure of the performance penalty of this, but I guess there is one. However, to compensate, all of GTK’s GTK_WINDOW, GTK_BOX, etc. are instead defined as simple pass-through macros. This means that performance wise it is a race between GTK_CHECK_CAST and qobject_cast.

I did consider putting the qobject_cast calls in the GTK_xxx macros, but that would not work. For instance, gtk_menu_shell_append can place a QAction in either a QMenu, or in a QMenuBar. As the function is given a QObject pointer, it can now determine (by casting) if the container is a QMenu or QMenuBar and act accordingly.

So, where to next? I belive in fixing the known bugs before continuing. Especially when working on a project such as this, which I suspect will backfire anytime soon (it has been too easy this far). This means that the next step is to do something about the GdkEvent structures to get the popup of the manual menu example to work properly (now it appears at a static location). After that? Cleaning and merging with gqt…

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.

#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

...

#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); }

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);
}
}