LXDE Blog

A Guide for Migrating from Gtk+ to Qt

Since I started learning Qt recently, I noted some issues when trying to port Gtk+ programs to Qt. There are tons of tutorials for Gtk+ and Qt, but a guide for porting is lacking. Most of the articles comparing Gtk+ and Qt did not go into detailed issues people will encounter during coding.
To help people porting their Gtk+ programs to Qt, I just started a wiki page documenting what I’ve learned so far.
http://wiki.lxde.org/en/Migrate_from_GTK%2B_to_Qt
Currently it provides a long table listing equivalent Qt classes for
commonly used GtkWidget classes. Since I cannot find a similar list with Google, I built one. This is useless for experts, but it’s very handy and helpful for Qt beginners who already know Gtk+. The mapping between Gtk+ and Qt classes is not yet finished, but I’ll try to make it complete soon.
I also documented things you need to know to safely mix glib/gio/GObject code with Qt. Later I’ll add docs describing how the translation systems differ.
I hope that developers interested in this topic can help edit the wiki
page to make it more complete and free from errors. It’s still a work in progress but I hope it helps someone as more and more people are using Qt and some more LXDE components *might* get Qt ports later. BTW, since Ubuntu guys is moving toward Qt, this also helps them.
Cheers!

PCMan

9 responses to “A Guide for Migrating from Gtk+ to Qt”

  3. I understand the \GTK vs QT\ discussion, both have their pros and cons and they follow diametrically opposite philosophies. GTK says reduce language requirements to the minimum so we can support any exotic system having at least a c89 compiler — we don’t need no stinkin OOP support in the language, the library can handle this. QT says, let’s start with C++, so we have at least SOME OOP support in the language while we still can reference C libs. Leave out the b0rked parts (exception handling), instead add language features missing (events and handlers, in \QT-speech\ signals and slots) — yep, they go so far to extend the language 🙂

    I don’t understand why you should look at \yet another toolkit\? wiki tells about fltk that it was for 3d graphics (huh?), but it supports creating GUI apps looking the same(!) on all supported platforms (wtf — i expect native look and feel from cross-platform gui toolkits). looking at screenshots, it looks a little like old GTK or even athena (ok, exaggerating here) — just outdated. No offense intended, I just don’t see the point. If it is JUST about the \lightweight\ property .. well, I think questions like \do users want to install a THIRD set of UI libraries on their linux box?\ or \are there any experienced developers for this exotic thing?\ could be a little more important.

  4. The answer is quite simple. Most applications are written in GTK+ and Qt, there is no third choice. For example, when you want to use browser, you still need those toolkits. All popular browsers(Firefox, Chrome/Chromium… etc) are based on GTK+/Qt.

    FLTK is absolutely lightweight and there is no need GTK+ and Qt, but it doesn’t mean that your desktop environment doesn’t need. 🙂

  5. Fred, your last sentence is one of my points, you DO have (most likely) GTK and QT installed on your *nix desktop. It’s a different story on Windows, of course. I tried linking a really small QT project I’m developing right now statically, the result is a 35,5 MB monstrosity (WITH –gc-sections), while the linux version using shared libs comes to around 320 kB. So, lightweight could be a benefit here.

    But then: how much can you add without losing the “lightweight” status? most projects start lightweight (think of Mozilla “Phoenix” ;)) and get somehow “fat”, you have to actively defend against that if you want to keep it small. And the other point: I didn’t try it live, but looking at screenshots, it seems fltk just doesn’t look very nice and probably feels “foreign” in your desktop environment. Ok, that’s just my impression from the screenshots, maybe it’s totally wrong.

    It may still be good to HAVE choices, I just don’t think it would be a good decision to base a desktop on something quite uncommon.

  6. Hi Felix
    Qt5 is modular. If you don’t need all the features you can avoid some parts and I’m sure you would get a smaller binary.

    KDE framework 5 will be also modular.

  7. I think porting LXDE to Qt is a very good idea.
    Qt is powerfull and lightweight enought.

  8. Does GTK3 follow the same path? I mean, that about supporting C89 and such. Because that would really be nonsense, considering it’s not exactly lightweight, you will probably need a modern computer, you can just use a modern compiler.
    About FLTK, its problem is, as said before, it’s lightweight by itself, but most apps in the *nix world use either Qt or GTK, and that means this lightweight library only adds a little weight (shared libraries imply that a part of their weight would be amortized as you use more apps, so a lot of apps using the same library will take less memory than a lot of apps using different libraries). It’s useful if you intend to make it portable without actually writing a frontend for every graphics library (including win32), since the easiest solution is static linking a small library, but that would be in a per app basis.
    About the extra clarification “it allows to build several GUIs that look the same”, I think that’s because FLTK has a long history, and it comes from times when that wasn’t the usual in *nix. And probably the old look and feel is because of the same reason.