Mathias Hasselmann

Back from Maemo Summit 2009

So I am back from Maemo Summit 2009. Great people. Great show. Great talks. Great venue: Enjoyed it quite much to walk arround in the Westerpark, Marc-André loved the petting zoo.

Hotest topic, of course: The N900. Thank you Nokia for lending those devices: Feels so good to finally have one for personal use! Finally got ideas for some private N900 hacking when reflecting responses to Travis' and my talk.

Another hot topic was DRM on Harmattan. Fortunately David Greaves came to similar conclusions like I've reached so far: Maemo Security - Lockdown or Liberation. Could be I'm just a weirdo, but I seriously hope for game developers targeting Maemo: Already called Rover "My next Wii" in jokes for its nice screen and the acceleration sensor.

Well, and then there still was this disappointment about Nokia moving to Qt as their prefered UI toolkit. Actually I wonder why people see this as problem: GTK+ was created without Microsoft or IBM holding our hands, so why does everyone expect Nokia to hold our hands for Maemo? If we really care about this platform, it should be absolutely possible for us to provide a proper GTK+ based toolkit for Maemo 6. Ideally Nokia would publish Layout guides and stuff early, so that we would not have to play catchup too much after device launch. Motivation and specs. More should not be needed. Really.


Javier Jardón commented on October 13, 2009 at 1:31 a.m.

Do you attend at the Future of Hildon talk?
Any news about it?

Mathias Hasselmann commented on October 13, 2009 at 1:50 a.m.

Javier, unfortunately not, as I had my own talk at the same time. Looking forward to see the video.

Simon commented on October 13, 2009 at 2:32 a.m.

It's fantastic that Nokia has embraced Free Software through QT.

GTK is too close to the GNOME/Microsoft/Novell alliance for comfort.

Murray Cumming commented on October 13, 2009 at 9:20 a.m.

Simon, you are a clueless troll.

michael commented on October 13, 2009 at 9:26 a.m.

Uhm I do not think there will be a video. At least I didn't see a cam. Anyway, for hildon it ultimately depends on the community's interest to port it to harmattan.

Most of the discussion was indeed about how new hildon widgets (from the community) would make it to the end consumer's device.

It is unlikely that new widgets can be pushed to the device in a timely fashion. I think a hildon-extras lib, entirely community-maintained, is the likely outcome of the dicussion.

michael commented on October 13, 2009 at 9:37 a.m.

also, for Maemo Security you might want to add your questions to Hopefully they'll be answered, too.

Simon commented on October 13, 2009 at 11:27 a.m.


You're a Microsoft sycophant, go code some Mono.

Take Jeff Waugh with you, he can convince us all how your coding contribution on behalf of Microsoft is good for us.

Mathias Hasselmann commented on October 13, 2009 at 1:11 p.m.

Simon, seems you are confusing things.

Probably my mentioning of Microsoft and IBM triggered some reaction within you, but please read my article again. I've mentioned them because they created the Personal Computer platform back in 1981 [1]. I really don't see how neutrally mentioning well known historic facts makes someone a sycophant.


Simon commented on October 13, 2009 at 1:26 p.m.

Mathias - "Muz" is a common abbreviation for the given name "Murray." My comment was addressed to Murray Cumming, the GNOME/Microsoft/Novell alliance's representative commenting on your blog.

Mathias Hasselmann commented on October 13, 2009 at 1:34 p.m.

Simon: What!? GNOME/Microsoft/Novell alliance!? ROFLMAO! Get a clue! Please!

andre klapper commented on October 13, 2009 at 1:55 p.m.

Simon: Enjoy hanging out with the Boycott Novell posse, but please don't hijack completely unrelated threads like you did here. Further comments will be ignored anyway as you are unable to provide proof for facts - hence there is no basis for argumenting. Personally I'm looking forward to the end of the school break so young kids spend less time in this new cool internet thingy that everybody wants to try out.

Dan commented on October 14, 2009 at 11:16 p.m.

Nokia bought Qt because it is a outstanding Gui. It is well developed from the previous owners Trolltech. Nokia made it possible for Qt to switch to LGPL. Hey don't get mad because everyone else in this realises that Qt is being developed for Maemo 6. Hell you got Chrome done in Gtk instead instead of Qt.

But not everyone still lives in the past thinking C is still the prefer way to do everything in gui when C wasn't meant for gui.

Mathias Hasselmann commented on October 14, 2009 at 11:38 p.m.

I don't get mad. Let them use what they want to use. Qt is an awesome improvement for Symbian. It made absolutely sense to buy Trolltech when it was for sale: 200+ smart hackers plus a well established toolkit for that little money. Awesome! Well, and now that Nokia had become a toolkit vendor it also didn't make much sense anymore to use a different toolkit for Maemo - from a long term point of view. Actually Nokia shall be glad to also have controllers with long term POV.

Still you get some facts wrong: For instance GTK+ has excellent C++ bindings, in contrast to Qt. ;-) Compare the signal systems of gtkmm and Qt. What is this parent pointer thing of QObject? And why do lead Qt hackers have to use the delete keyword when show casing Qt? Hello smart pointers? (Not that the memory management of gtkmm would make much sense, btw. The maintainers know.) Also quite nasty: Their idea of overloading potential variable names with preprocessor macros. An example that comes to my mind: Their foreach macro. Just ridicilous.

Many other things come to my mind. A top notch toolkit looks different. But in the end it absolutely doesn't matter which toolkits people prefer. If Maemo remains as open as it is right now, you can use whatever toolkit you want. Nokia just won't hold your hand if you use something different than Qt.

Dan commented on October 14, 2009 at 11:56 p.m.

You're correct. There is Gtkmm for it. Works nice, I will admit that. But the documentation sucks for it and is a pain to compile on Windows.

The reason of the parent of QObject's etc is for the parent child relationship so you don't have to worry about messing with deleting everything yourself.

Qt has QScopedPointer, QSharedPointer etc. There is nothing wrong with foreach. Just because it's not the std::for_each? Or because C++ just never made a foreach keyword.

If you want to talk about things like that. Why does Gtk have to reimplement the OO wheel when C++ has it. Look at how when using Gtkmm. There is like 6 different smart pointers you have to use on different modules like Glib, Gio, etc.

I mean why can't Gtk just be done in C++? Instead of reimplement the wheel of Object Oriented? Don't give me the bindings stuff. Because look at KDE. They use Smoke to generate bindings for Perl, C#, Ruby, etc.

I'm not saying Gtk is crap in any way. But doing gui in C is very retarded nowadays (no I'm not calling you retarded or anyone else).

Mathias Hasselmann commented on October 15, 2009 at 12:17 a.m.

Dan, exactly: "foreach" is not a keyword. It's a lowercase identifier. Lowercase identifiers usually are used for variable names and argument names. Preprocessor macros shall avoid lower case names, especially when used without namespace. This only causes havoc:

class FooBag {
public: void foreach (Callback cb);

Real world example:

See for details. Poor Dave spend quite some time on this, when trying to create a Qt port of Glom.

Dan commented on October 15, 2009 at 1:05 a.m.

If you want to complain about Macros. Look at wxWidgets ;)

michael commented on October 15, 2009 at 1:23 a.m.

Dan, "Why does Gtk have to reimplement the OO wheel when C++ has it?" - fine, I'll bite: Why doesn't Qt use the type-safe signals provided by libsigc++? Why wasn't Qt developed in Eiffel, which had much better OO support than C++ back in the nineties? Why did C++ copy all the OO stuff from Simula instead of just making Simula faster?

I can play this game, too. Probably even better than you =p

Dan commented on October 15, 2009 at 1:52 a.m.

Why doesn't Qt use the type-safe signals provided by libsigc++?

Qt signals/slots are type safe. They won't work if the types are mixed, you can even emit some parameters also. Qt invented the signals/slots back in 1994. That's why they don't use libsigc++. Qt's signals/slots also adds the Qt Meta Object system to Qt. So why throw that away. Before bashing that. Look at QtScript, its done very easy via the meta system created by the signals/slots.

About the Eiffel/Simula I have no idea about. Never read about it and never used it so I can't comment on that.

But you never answered my question.
"Why does Gtk have to reimplement the OO wheel when C++ has it?"

If you wanna complain about macros. You have to use macros all over the place with Gtk.

Why does Gtk claim to not emulate system visuals, yet the menu's do not look anything like the menus in Windows and doesn't even support Cocoa/Carbon afaik. When Qt does.

In order to do anything useful. Everything is a dependency in Gtk.

Murray Cumming commented on October 15, 2009 at 10:31 a.m.

> There is like 6 different smart pointers you have to use on different modules like Glib, Gio, etc.

This is not true. There's Glib::RefPtr, and Cairo::RefPtr, because Cairo doesn't depend on glib. We'll stop having even them when the Standard C++ Library has real smartpointers, hopefully soon.

I'm not particularly happy about how much Glib::RefPtr must be used these days, now that so many extra APIs use pure GObject. It rarely appeared in application code back in the gtkmm 2.0 days. We may rethink it for gtkmm 3.0.

I'll ignore the other subjective stuff because I'm not interested in a pointless argument.

Mathias Hasselmann commented on October 17, 2009 at 11:06 a.m.

Dan: So if the OO support of C++ is perfect, why did Qt had to add signals and slots via some preprocessor. Why does QObject's dynamic introspection system look that similar to GObject? If C++'s OO support is perfect, why didn't Qt reuse STL containers?

Questions over questions.

Now add insane defaults like implicit vs. explicit ctors, non-virtual destructors. Finally throw in the bad C++ support of gcc 10 years ago, and you start to get an idea why choosing plain C for implementing a dynamic object system isn't half as absurd as you claim: You'd have to implement most of it anyway. Just compare QObject and GObject...

So if you have to do that, why not choose a language that's easy to understand and has only few traps? It's a compromise. Guess grandfathers of GTK+ would have to be happy if they could just have taken an dynamic object sytem from the shelf. Well, and now with all the bindings language preferences are secondary anyway. Actually even the toolkit is. More important aspects are documentation and helpfulness/friendlyness of the community.