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

Don't see the problem

[Bastian]

I do C++ programming with C libraries and API's all the time. It's not like C++ can't interface with C libraries. . .

If you absolutely need to have it be OO, it's not too hard to write wrapper classes for all the functions you'll be doing. For OpenGL work I have a few classes of that kind that I use a lot - a camera class, for example.

Re:Don't see the problem

[Webmonger]

Ah, but why write your own wrappers when someone (and not just someone, but lots of people) has written wrappers for you? Why worry about the design when there's a design already done and reviewed and redone?

Give me a good reason to reinvent the wheel, and I will. Hell, I used to reinvent the wheel for bad reasons or no reason. Wanna see my StringBuffer class? Didn't think so.

I've been using gtkmm on a little project of mine, and it's quite nice. I used gtkmm to give a gui to du. Used code from 2 different open source projects to do what I wanted.

Every line of code you reuse is more likely to be right than every line you write. If it's already been written, if it's already been tested, it's one less thing to worry about.

Re:Don't see the problem

[Pseudonym]

It's not like C++ can't interface with C libraries. . .

It's often pretty painful, though. Off the top of my head:

• Complex C APIs, especially GUI systems (e.g. Win32, Motif) often try to implement an object model themselves, which usually doesn't map well onto C++'s object model.
• APIs with callbacks are almost never exception safe.
• Varargs at the C level usually implies const incorrectness at the C++ level.
• Don't get me started on concurrency, though at least modern C APIs tend to get this right.
• Memory management/ownership issues occasionally crop up, though this is a bit more rare in a well-written C API.

Re:Don't see the problem

[mbrix]

Go see the gtkmm FAQ: Why use gtkmm instead of GTK+?.

Working with STL-style interfaces, and having the chance to use std::string and std::vector to input data to your widgets is just *great*.

Of course, all the other advantages of C++ can be used as an argument on why to use the C++ interface.

You never mentioned why you don't want to use the C++ interface, maybe you should mention what you consider the disadvantages.

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?

[__past__]

In one word: moc

Re:Qt bad gtkmm good?

[JimDabell]

Moc? Moc is simply a preprocessor to add on language support for the signal/slot methods. If you remember, C++ started out as a preprocessor for C. OK, so it might not be kosher C++, but it's much more intuitive to do things that way than with base-classes, etc, that you see with other C++ GUI techniques.

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.

Re:chill

[PD]

That redundant moderation betrays the festering pile of maggots between some moderators' ears. This wasn't redundant at all.

It was funny. Funny in a sophomoric way, true. But it ain't redundant.

Posted with my +2 cluestick.

Virtual mod point to you

[GCP]

Very informative. Thanks.

Critiques of Qt and Inti

[Karma Sucks]

This guy can't even spell Qt right, let alone criticise it. I'd advise using Qt first before making off the cuff remarks like that.

The whole reason for Inti's existence is to compete with the ease and power of Qt. Sorry but the latest m&m release doesn't even come close to matching Qt in the terms of ease of use and power.