Murray Cumming on Programming for GNOME with C++

GonzoJohn writes: "Christian Fredrik Kalager Schaller for Linux Orbit: 'If you have followed GNU/Linux for the last few years you know that GNOME has long been a stronghold of C, Perl and Python GUI programming. With Ximian's work on Mono, C# seems also to be a language that will see wide use in GNOME. Sun's involvement should also make Java applications integrate strongly with GNOME. But what about C++? Even in the GNU/Linux and Unix world this language has received many advocates and developers. I sat down with Murray Cumming, lead developer on the gtkmm and gnomemm C++ bindings for GTK+ and GNOME to get some information on the status of C++ development in GNOME.'Read the Interview."

Comments

Qt bad gtkmm good?

[pmz]

Can someone clarify what the awkwardness, bizzareness, and insanity of Qt are? I've used Qt on a couple of small projects and found it pretty intuitive. No flames, please, just a couple of good arguments.

Re:Qt bad gtkmm good?

[Seli]

There aren't any really (well, at least not more than in other pieces of code). Let's for example have a look at the table comparing gtkmm and Qt linked from the article (this one http://www.murrayc.com/murray/talks/2002/GUADEC3/s lides/html/img6.htm). For a guy who's supposed to know C++ so well his arguments have rather weak base ground, so he's either not that good, or he's just badmouthing Qt without knowing the things.

Moc extends C++: Oh yeah, telling this to people believing moc is a preprocessor can be hard, but moc extends C++ about as much as Doxygen. Moc is a code _generator_ (or call it precompiler), it's not needed to preprocess the sources, programs written in Qt are valid C++, otherwise one wouldn't be able to compile it with so many C++ compilers. What moc does is it analyzes headers files with few tags added, and for reasons like making it easily readable those tags are created using few #define macros. If TT wanted, they could be written in comments, just like for Doxygen, and it would be perfectly perfectly pure C++, yet there wouldn't be any real difference. In fact, it would be possible to write Qt code even without moc, but one would have to hand-write all the generated code, and that would probably get some people in madhouse.

Containers: Qt has to run on a number of quite old and crappy platforms (unfortunately, I'd be happy if TT dropped the support for them too). That's the real world. It's easy to limit a brand new library (which gtkmm2 is) to using things like that, but there are still C++ compilers in use that can't handle things like that. Some key design decision for Qt were made many years ago, and some (paying) developers wouldn't be happy if Qt completely changed every year. Moreover, Qt3.x has support for STL (I don't know how good though, I don't use it), and maybe Qt4.x will have its own containers only for backwards compatibility, and will prefer STL.

Namespaces: Qt is in a sort of namespace, and it should be sort of namespace clean (everything starting with Q). Since for KDE4 it's planned to have it completely namespace clean, including plugins, etc., Qt4 will be maybe in its own namespace too. Not that putting it in a real C++ namespace will make that much difference.

Memory management: One can delete widgets in Qt, and they will be automatically removed from the parent, who's otherwise responsible for the deleting (and getting used to this simplifies things). It's also not true you can't create Qt classes on stack, I do that sometimes when it fits. The truth is that it doesn't fit most of the time.

GNOME classes: Let's skip this one.

Widget containers: I don't know enough about the way it's done in gtkmm, so let's skip this one too. It's doesn't matter much anyway, I don't have any problems with separate layouts in Qt (in fact it may be easier to code the layouts that way, but that's just a guess).

Typesafe signal handlers: Well libsig++ has its problems too, like possibly increased compile time with already slow enough g++, and the compilers need to be very good at handling templates, which g++ wasn't not that long time ago. http://doc.trolltech.com/3.0/templates.html might be a good read in case you wonder why Qt still uses moc and not libsig++.

License: The table misses QPL and commercial licenses for Qt. TT developers also have to eat, and people need to be payed in order to e.g. write as good documentation as Qt's is (just compare it to gtkmm's). If you can't handle the fact somebody tries to make money and yet is so Open Source friendly, just shut up, ok? I can undestand some people prefer Gtk+ just because of LGPL, but that's no reason for TT bashing.

Development: There are at least two places where Qt is discussed, for the first one see mailing lists section on TT www site, the other place is KDE lists. For a commercial company, their handling of bugreports and suggestions is quite good. (Not to mention that those FSF fanatics screaming about Qt not being Free(tm) should actually love it - it's GPL'd, not LGPL'd and that's the one true RMS way, isn't it?)

I'm not saying Qt is a perfect thing. Nothing is. There are certainly things that could be better, some of them are there because of the wide platform support, backwards compatibility, some of them are there for other reasons. But there's no valid reason to call Qt bizzare or insane. It's one of the best toolkits in the world, and I mean it.

chill

[austad]

Murray Cumming on Programming for GNOME with C++

I like programming for GNOME in C++ as much as the next guy, but Murray just needs to calm down a bit.