Going Home
I’ve spent the weekend at GUADEC in Gran Canaria but I fly back today to be at home for wee Liam who I really miss. I’ve noticed that people didn’t really understand that for the past year and a half I’ve spent half the week taking care of him, and the rest of the week running the company and doing just a little coding. We should have a place in a crèche in our street starting in October so things will eventually get back to normal.
In the meantime it’s been great to see old friends but I can’t talk about doing much public work in GNOME recently, or promise to help with things.
Maemo and Qt
It’s a relief that Nokia finally announced, via Quim, that they will use Qt instead of GTK+ in future versions of Maemo, though the next version, Fremantle (Maemo 5) is still entirely GTK+. Openismus have known about this for some time and have been preparing for it, but we couldn’t talk about it. As enthusiastic C++ developers, this is less disappointing to us than to other GNOME companies, and it’s been great to see Qt’s development gradually open up to the outside world.
However, it’s clearly a rather arbitrary and disruptive decision. I suspect that some managers are dictating the Nokia-wide use of Qt even in projects that don’t otherwise share code, without understanding the difficulty of the change. UI code is never just a thin layer that can be replaced easily, even if it looks like just another block in the architecture diagram. Likewise, hundreds of C coders cannot become capable C++ coders overnight. I expect great difficulties and delays as a result of the rewrites, but Openismus will be there to help.
Openismus T-Shirts
The economy has affected the traditional GUADEC T-shirt supply, making the Openismus T-shirts even more desirable. Introduce yourself to David King if you’d like one of the last ones from his backpack before he leaves on Tuesday. André, Karsten, and Johannes are here too.
This cross-desktop conference is ideal for David because he’s been intensely learning about all of GTK+, gtkmm, and Qt in the past few months.
Strange to read on planet gnome that someone is happy that Nokia dropped Gtk+ in favour of Qt.
Iariq, I don’t think “happy” is quite right.
Well, since Qt 4.5 it’s perfectly possible to write GNOME apps with Qt, so that’s not really bad news for the GNOME camp.
However, I’d like to ask why “other GNOME companies” are more disappointing and who those “other GNOME companies” are.
Markus, companies that don’t do C++ are likely to be disapointed (not “disappointing”).
If only Qt were C++…
I find this whole thing quite strange – It seems very unnatural to get the diktat from above, without any sort of technical justification.
– While I like both GTK+ and QT, it seems that Maemo will end up with a sort of unholy mix of the two.
– While I’m sure that all the small opensource companies involved will work out a relatively smooth migration path, it seems like it’ll take a lot of work and time. Time that maybe would have been better spent on maturing and establishing Maemo.
– There will likely be quite a few developers that lose faith in Maemo over this. Not because they hate QT or anything like that, but because this shows that very arbitrary decisions can be foisted on the developer community at any time in the future. While keeping everyone in the dark for a long time. I for one will definitely not invest any more time in the Maemo platform.
– It seems like it’s not the only thing where there’s a decision for business reasons rather than technical reasons. The grapevine tells me Nokia vetoed Webkit and ruled in favour of Gecko because of perceived influence of the competition (Apple and the iPhone, I suppose).
On the upside:
– Maemo may attract a lot of new developers from the QT side. (I still suspect it’ll be a net negative with the people abandoning the platform, though).
– The “unholy mix” may make it easier for both the QT and GTK+ side to adopt and share more of each others’ technologies. Maybe Maemo will be able to act as a focal point for sharing and maybe unifying some of the tech. A ‘freedesktop.org’ in practice of sorts.
Marcus, maybe I missed something but a gnome app written in qt will behave and feel differently from a app written in gtk.
So how can a Qt 4.5 app become a Gnome app?
Maybe you are talking about that qt using gtk theming engine. It’s still not the same.
If you are talking about licenses: That never was a problem, as most gnome apps are GPL themselves.
I think Gtk+ people are disappointed that more people actually want to move away from C. Because C++ actually offers alot more than just C does.
@Daniel Elstner:
Qt is C++. where has your head been? If you mean C? Well sorry C doesn’t offer alot of support like C++. Yeah C++ was written with C. But you have too many hacks just to do what C++ can do out of the box.
@Daniel:
You can’t write Gtk+ in Qt. They are two different api’s. Qt does have Glib which makes it possible to write plugins for Gtk+ apps and the alike.
@Lariq:
It’d be nice if Gtk+ actually had a style builtin to use Qt style for Gtk+ apps like Qt does for Gtk+ apps. But the developers of Gtk+ only care about themselves in my honest opinion.
@Zeke: No, I didn’t mistype. I don’t like Qt precisely because of “too many hacks just to do what C++ can do out of the box”.
@Zeke:
I don’t know which planet you live on, but on mine there is a gtk2-engines-qtcurve package, and a gtk-qt-engine which actually makes GTK+ widgets paint themselves via Qt. I am not aware of anything even close existing for Qt, apart from a number of unsatisfying theme imitations. If there is such a thing, I’d like to know so I can use it.
@Daniel:
Yeah I know about that. But I have to download another app, to even get it. It’s not in Gtk+ like Qt has it in there for Gtk+.
You talking about MOC. I wish people would get over that. You must hate apps that use boost::spirit or even gcc. It generates code too?
I don’t like Gtk+ because it’s theme is ugly. All those underscore’s. Documentation lacks badly. Too barebones. Too much work to even hook up signals. Gtkmm isn’t a real alternative. It’s documentation lacks too. It’s a pain in the arse to install on Windows. Barebones too. And why use C when C++ offers more features like polymorphism, classes, inheritance, smart pointers, etc.
@Zeke:
As far as I know Qt ships as multiple packages, too. And that’s how it should be. It’s called “modular”. Apart from that, the theme engine which draws using GTK+ is not included with Qt either, because there simply is no such thing.
As for getting over MOC, may I quote you again? You argued against GTK+ saying it has “too many hacks just to do what C++ can do out of the boxâ€. But the GObject system is useful in the language it was written for. Qt, on the other hand, replaces C++ features despite the fact that it is targeted at C++ anyway. It was your own argument — stick to it.
Spirit uses C++ features heavily to implement recursive parsing at runtime. What was your argument again? And funny how g++ is just that, a C++ compiler. It does not replace C++. It implements it.
Frankly, I don’t care myself whether gtkmm is hard to install on Windows, as long as it works at all. Anything else beyond that is up to people who contribute to gtkmm on win32 in order to make it easier to install and use. It is not a priority for me personally.
As to “barebones”, I’d like to see that defined first. I like the way the GTK+ and gtkmm stack is layered. I also happen to dislike the Qt coding style, just as you don’t like the underscores. The documentation is indeed lacking, but it is good enough for me and I very much prefer the non-idiosyncratic API.
And why use Qt “when C++ offers more features like polymorphism, classes, inheritance, smart pointers, etc.”? It works both ways.
@Daniel:
QGtkStyle was integrated into Qt in 4.5.0. Well Moc is the Meta Object system in Qt. And you don’t ever even mess with the moc file itself. It’s done in the background of the compiling. Why would it bother you? It replaces std::list, std::vector etc? Well Qt had it way before the standard iso of C++.
You do know that Qt isn’t a language. It doesn’t replace C++ or anything like that. Even wxWidgets which is a wrap around of Gtk+. It has wxVector, wxList, etc also.
Regarding QGtkStyle, I stand corrected. So Qt now has this feature too since its latest release, which is great.
As to MOC, you said it already: “Well Moc is the Meta Object system in Qt”. It is a meta language, with its own parallel runtime type hiearchy, its own signal and slot mechanism, basically its own everything.
By the way, I’ve been using STL containers for about 10 years now. Qt has had API and ABI breaks in the meantime, so there is no excuse — it’s a decision that was made deliberately, and I happen to not agree with it. You are right, people used their own data structures before the STL. They also used C before C++ was widely adopted. And some people still code in COBOL. Some people still work *on* COBOL, in fact. You are again reversing your argument in mid-discussion.
Qt does ship with and depend on its own meta language processor. That’s obvious. And it does replace C++ features, because you can implement a better signalling framework than the one implemented in Qt/MOC in plain C++. Guess why I don’t like wxWidgets either.
@Daniel:
Heheh, I have nothing against Moc at all. It’s there for a reason and it’s actually very good at what it does. Yeah I’m sure there are probably better ways. But I don’t like the way Gtkmm does it to make a signal/slots. And it’s alot better than MFC and wxWidgets message map stuff. wxWidgets just tries to be another MFC api but without the hungarian notation.
I personally like Qt because it’s company developed behind. Everything I need is in one simply download. New features are always added. QtDBus, QtScript, QSslSocket, QtWebKit, QtSql, there is QGraphicsView, etc. What move could you want? the documentation is great. Not really into the QMake, but I use CMake anyways. That’s something Gnome needs to pick up and stop using autohell. There is the great community behind it QtCentre, #qt on freenode, the ML, even professional support. There is an add-in for Visual Studio’s, there is an add-in for Eclipse, you have KDevelop4 which runs on Windows and Linux. It handles all the pointers itself except where you don’t inherit from QObject. Fully featured api. There is an animation module. Basically wraps tons of calls especially where it’s pain in the arse to do on Windows.
So now that we’ve got the real arguments out of the way, it’s down to taste. Well, I happen to dislike almost every single feature from your list of points in favor of Qt. I very much prefer the sigc++ signal system. I even prefer autotools over many other build systems, in particular QMake. It has served me well and is very flexible and powerful.
I have to say, people’s criticism of moc always amuses me. “OMG! Code generator!!” moc actually does very little in Qt. Take a look at the generated code sometime. It generates a little metadata, the equivalent of which GObject coders tend to type by hand (assisted by a few macros), so that you get runtime types (C++’s types exist largely in the mind of the compiler). It also generates marshallers for methods, which GTK+ also provides a generator for (or you write it by hand). It’s really a silly thing to complain about. What is a more valid complaint is Qt’s signal/slot mechanism, which is slightly less flexible than I, personally, would like. It does store information on a per-class basis though, something else facilitated by a moc.
Sadly, gtk-qt-engine isn’t quite up to scratch. It’s not worked on by quite the same number of people as Trolltech’s QGtkStyle. QGtkStyle is done very well, which is surprising given how hard GTK+ makes this task. GTK+ lacks a working drawing API; you cannot pass in a transparent pixmap and ask GTK+ to draw the widget. GTK+ premultiplies a specified background color, so you have to instantiate the widget and then draw it *twice*. Once on black, once on white. Then, you download both pixmaps from the X server, recover the alpha information, and reupload to the server. This is an extremely slow process that both QGtkStyle and Mozilla have to go through. QGtkStyle I know caches this image (which only works if the widget never changes sizes). I imagine Mozilla does as well. I suspect this is one of the reasons why Chromium doesn’t bother using “native” widgets in the browser area on Linux. Qt, in contrast, can do that and can even draw onto an arbitrary QPainter context and provides mechanisms for implementing a QPaintEngine backend for your painting engine. (In practice, people usually just go the pixmap route though.)
Qt, in general, has a much nicer and mature API. I hope someday GTK+ catches up; it is sadly the de facto Linux standard and seriously lacking right now. In the meantime, Maemo made a good choice.
David, it’s C++, not moc, that makes the big difference when comparing GTK+ to C++. Personally I’d rather do without moc and just use regular C++ as we do with gtkmm.
But you don’t need to convince me that C++ is nicer. The point is that it’s a sudden massive rewrite in an unfamiliar programming language that ignores the existing base of developers, both inside and outside Nokia, and ignores the existing code base. A great deal of time and money has gone into building up that base of developers and code.
@Murray:
Besides the C vs C++ thing (which as I see it really is very much depending on your taste) what would you say about GTK vs Qt as toolkits? And if you say “well Qt does a lot more”, then what about the stuff they both do?
I agree that the choice by Nokia to move to Qt is a painful one, and they will have to pay dearly. But in the long run it is probably the only way for them to remain competitive – GTK/Gnome simply didn’t deliver.
monkey, I don’t think that’s clear at all, and nobody has suggested that the switch is based on anything remotely technical.