Slashdot Mirror

First, gtk+ is for C, while qt is for C++. Another major difference is that qt is more than just a widget toolkit, but an application runtime environment that provides widgets. This means that qt provides string handling, database connectivity, etc., although you don't have to use anything but the widgets and application objects, if you wish.

I thing maemo is mostly written in C, so some parts will probably have to be rewritten in C++.

This article may help a bit, although it only compares qt with gtkmm (the c++ bindings to gtk):
http://www.telegraph-road.org/writings/why.html

This article should be taken with a grain of salt, as it's pretty old, and may be inaccurate today.

I started using gtk+ with python, way back in the 1.x versions. The 2.x bindings for python were much better, allowing me to write more pythonic code using gtk+.

Later on, I decided to try out qt3, and I haven't looked back since. While it took a bit of getting used to, I found that it was easier to use qt, rather than gtk+, although I'm hard pressed to figure out exactly why.

One of the things I liked about qt over gtk+ was the separation of the layout widgets and the interactive widgets. Coming from gtk, this was something that took me a while to understand, but once I got the hang of it, I liked it, and think that it's a better way to organize the widgets. With gtk, a vbox holds child widgets, such as buttons, labels, etc. So if you want to rearrange them in an hbox, you have to destroy those widgets and make new ones in the hbox. In qt, the layout widgets are of type "layout", and you can only have layout children in layout widgets. The interactive widgets are children of the main widget (or a child widget of the main widget). These widgets are "placed" into the layout, but can be removed without being destroyed, allowing you to rearrange the layout more easily.

I also prefer the signal/slot mechanism in qt over the callback mechanism in gtk. On the average, it makes it easier to glue your widgets together, but there are a few circumstances where a callback mechanism is preferred, in which case you have to invent a new signal(s) and chain them together. This is because there is no order of slots called when a signal is emitted.

Also, the qt documentation was better, more organized, and easier to read than the gtk docs (at least around the time I switched ~2004).

Probably the largest reason why we're even having this discussion is due to licensing. Gtk gained a lot of popularity, due qt being licensed under the trolltech license, which restricted developers from using the free version in commercial products. The switch to gpl didn't do much to change this, although you could then create commercial products, but you also had to release the source for those products. So if you wanted to keep the source closed and use qt, you still had to purchase a commercial qt license.

You mean this one one?

Just for the fun of it, I've written a quick reply : http://www.telegraph-road.org/writings/linux_deskt op.html

http://www.telegraph-road.org/writings/gtkmm_vs_qt .html

It's a really interesting read.

No I don't... he even started in GTK+, then moved over to GTK-- and finally QT was the magic word... But still... 4 hours compiling for QT, KDE, Rosegarden is no fun.

Just get a C++ wrapper like gtkmm and you are there.

This kind of reasoning shows perfectly what's wrong with GNOME as it currently stands.

Simply because there exists a C++ wrapper doesn't mean that, quote, "you are there". Far from it.
Likewise for UI designers and IDEs.
You may want to read this article by a former gtkmm developper who since switched to Qt. In particular, read this: "The bottom line is that about a month after switching to Qt/KDE, I had made more progress than in the past 3 years." Read it several times. Don't forget that this guy was one of the gtkmm maintainers.

Same problem for Anjuta and Glade. They exist, alright. I've evaluated both when reviewing open source development tools. They don't come anywhere near competing with KDevelop and Qt Designer, respectively. I can only encourage you to personally review both, over the course of some small to medium-sized personal project, for example.

In the meanwhile, you can either go on pretending that "you are there" with the tools you've listed. Or you can get to work and fix them. Just please don't expect people to waste their time on, for lack of a better word, amateur-class software just to comfort you in your current biases. Thank you.

> Derived objects, on the other hand, don't seem too useful for GUIs
> so long as you have interfaces or a good implementation of generic
> functions and type inference.

That's where you're wrong, with my apologies for putting it so bluntly.

Derivation is the #1 thing that makes the difference between a good widget set and a bad one, for several reasons.

The major reason is that in any complex application, you'll need custom widgets (entry fields with browsable history, viewing pane with custom repaint, etc). If you have to provide the functionnality by manually appending it to the native widget everywhere it's needed, your LOC (and the potentiality for bugs) explodes. The right way is to derive a self-contained widget from the general case, specialize it for the need once for all, and use it instead of its parent where needed, which only requires adding code in -one- place.

Typical example is KDE's file dialogs, that all derive from a common root, but can be expanded on an as-needed basis (and without even adding bloat since the common logic is in the parent class).

Typical counter-example is the MFC, which are absolutely awful to code against, because they're based on a non-object-oriented framework and have very little extensibility (WinForms is thankfully a major improvement in that regard).

Second important reason is granularity. Derivation allows an API to provide very high-level widgets (text editors, MDI areas...) -and- their lower-level parents, which in turn allows you to use the high-level widget where it's the fitting tool, and derive your own from the parent where it isn't, all the way down to the lower level widgets if they're what you need. Lack of the extensibility derivation offers in an API means your API will either have to remain very low-level, thus requiring you to reinvent higher-level wheels everytime you'll need them, -or- overbloating the API with countless specialized widgets to try to cover most of your needs (that's the MFC approach).

Typical example of why that matters is GTK's handling (or lack thereof) of MDI interfaces. Another saddening example is Gimp 1.3, and the considerable amount of time that has been spent on nothing but interface code rather than actual features.

Third reason is, of course, as you rightfully point out, event handling, which derivation allows to specialize as needed (for instance, tablet XInput events on a drawing widget -- see how Qt does it for a good example) -without- building a dedicated widget from the ground up -or- special-casing against XInput. Once again, Gimp 1.3 and its XInput handling problems are a good example of why it matters.

There are no two ways around it. There is virtually NO pure-C widget API left in existence (if you except GTK, which pays it dearly in LOC and slowness). This is not without reason.

Once again, I'm sorry, but while you're right about event handling, that is a -runtime- issue and pretty much orthogonal to widget development. You'll note, by the way, that Qt provides signals and slots -precisely- so that you don't have to think about that orthogonality in the common cases -- its widgets handle events on their own and emit the appropriate signals as required, which allows you to design your code according to WHAT is to be done in response to something, as opposed to HOW that something happened. Best example is the concept of QAction, which can be triggered from a butten, a menu, a context menu, or a key shortcut. You only have one signal to slot against, regardless of which way that action was triggered.

There, that's it for now. I hope I managed to make it a bit clearer why object orientation is primordial to a good GUI toolkit?

Rosegarden developper Guillaume Laurent has a few interesting thoughts about why he switched from a GTK-based backed to some random object-oriented toolkit, if you'd care for a slightly different point of view on the same topic.

Wicked! I get to catch no other than Bruce Perens himself posting a sizeable but subtle fallacy. I suppose that I get to really feel cool now, in a geeky sort of way. Anyway. Apologies, Bruce, for I strongly doubt you did it on purpose, but here it goes!

> One nice thing about GNOME is that a commercial license is not
> necessary to write and distribute a proprietary GNOME application.

*clears throat*

"One nice thing about paper and pencils is that a pricy PC is not necessary to design and write loads of code."

I mean this seriously, and this says nothing either for or against paper and pencils as opposed to computers.

Only, well, in both cases, the right tool will simply save enough time to make the cost well worth it.

And before some excited kid mods me down for daring to disagree with Bruce, let me tell you that if you've never used paper and pencil to design a piece of code you just thought up where no computer was at hand, you don't deserve your /. geek points.

Different tools work well in different circumstances, that's all. Deal.

And in this specific case, it is not unlikely there's a reason why one of the Linux desktop environments has more proprietary companies developping for it than the others.

Food for thought, I hope.

(Having karma to spare is a nifty thing, you get to speak plainly and maybe get people to think. That's way cool.)

Bali out.

Incidently, Guillimue (I'm sure I mispelled his name) Laurent, one of the GTKmm designers, got fed up with how difficult it was to cleanly do a GNOME C++ API (unlike GTK), and ended up moving to Qt.

You indeed mispelled my name :-). You also totally misunderstood the reasons why I left gtkmm. They are explained here, and they have nothing to do with the difficulty of wrapping Gnome as opposed to GTK. Ask Murray Cumming if wrapping GTK+ is easy :-).

That said, I'm indeed extremely happy to have moved to KDE/Qt, even if that wasn't the reason why I left. Sooner or later, it would have been anyway.

Have you extensively used these bindings yourself ? I hereby challenge anyone to port Rosegarden to a GTK+ binding (any binding, Python, Perl, C++, pick one). Or even to write an app which has half of the features Rosegarden currently has.

See this for more details on the problem.

Qt has only one major problem: it's written in C++.

This is actually Qt's greatest asset.

But that one's a problem from which I have never seen a toolkit recover without the marketing dominance of Microsoft.

You should go out more often : RogueWave
Ilog

try to get an average-skill C++ developer up to speed on a project that's been under development for a year or so, and you'll be spending months explaining why you used the language the way you did

Too often true in practice, not true with Qt/KDE.

You know, that language that Linux, X, GCC, BSD, Apache, Bind, Sendmail and most of the rest of the civilized world's software is written in.

As I said, you should go out more often. There's a whole universe outside of the tiny rosy world of free software.

If you want to use a C library from C++ you can.

But it's highly suboptimal. Frankly it generally sucks big time.

The matrix is a little hard to read because there are so many languages in it....

And how many are complete enough to actually be used to develop a big application right away ?

The conclusion of my experience of 3 years helping to maintain Gtk-- and trying to develop with it, followed by 1 year of programming with Qt professionnally and with Qt/KDE at home is that Qt/KDE is, without a doubt a vastly better and more productive development platform than Gnome is at this time.

The language bindings point is totally moot, and after all these years and so few mainstream Gnome applications written in anything else than C, may be people should re-evaluate it. I wrote about it two years ago already, and as far as I can see most of my claims are still true.

When I started using Qt at work, I found myself to be more proficient with it after just a few days than I ever was with GTK+ or even Gtk--, where I constantly had to lookup either in some barely existant documentation or at the source code itself, or needed to add yet-another-wrapper for some strange struct I'd need.

A direct consequence of this is that whenever I wanted to write a patch for a KDE app, even fairly large and old ones (konsole, kmail), I could get a moderately complex feature done in just a few hours, over code I had never seen before.

Contrary to what you think, the level of entry of KDE for a programmer is way lower than for Gnome. Even a C++ beginner can produce useful code after just a few days of learning. This is not true for all C++ toolkits or projects, but it is true for Qt and KDE.

This is the reason why KDE's development pace is so quick, and why so many high-level applications like konqueror, kdevelop, or koffice could be written by teams of less than half a dozen people. Programming under KDE is just so easy.

I suggest you try it. You'll be surprised, as I was too when I switched.