Nokia's Maemo Switching To Qt

suka writes "During a keynote at the Gran Canaria Desktop Summit, Nokia's Quim Gil announced that a future release of Maemo is going to be built around Qt. Maemo Harmattan is going to switch away from GTK+ / Hildon, derStandard.at reports from the conference." Michael Pyne also writes with a post describing day one of the conference from a KDE perspective.

Comments

Re:I know why..

[Kjella]

I know why.. Because QT was released under the LGPL, sorta recently.

Uh, maybe because Qt was bought by Nokia? They're the ones who decided to LGPL it, but they can do anything they want with it.

I wonder about this

[erroneus]

There is a lot of software for the Nokia N810 and below. Switching out to a new UI means a lot of stuff will either get uprooted or there will be a lot of libraries loaded into the machine's precious little memory.

Still, if the developers of software port over to the new environment quickly enough, it won't matter but I can't imagine things will be quick enough.

What can be done under Qt that can't be done under GTK? Is Qt more efficient in some way? What are advantages of Qt over GTK? I've never been clear on the differences... I just know they are different.

Re:I wonder about this

[abigor]

Qt is not just a gui framework. It provides a massive amount of extra stuff. Browse the documentation: http://doc.qtsoftware.com/4.5/index.html/

Note the WebKit integration, multimedia framework (Phonon, which was a part of KDE and later folded into Qt), OpenGL support, etc. etc.

Comparing it to GTK is like comparing a full-fledged desktop like KDE or Gnome to Blackbox.

Re:I wonder about this

[ricotest]

First and foremost Qt is not just a widget toolkit. It is a full development environment: it has a build system (qmake), a fully-developed IDE and widget layout editor (Qt Creator) and many, many extra libraries. To quote just a few examples, there are classes to handle tray icons (whether in KDE, GNOME, Mac OS X or Windows), classes for running TCP servers, integration with the Phonon media framework, the WebKit browser, SVG, databases, multi-threaded code and even scripting support using QtScript, an implementation of ECMAScript (JavaScript).

Qt is written in C++. GTK attempts to do object-oriented code in C and the result is a mess of explicit casting and macros. Seriously, most GTK C code looks horrible and is far less terse than the equivalent Qt program. This is mitigated when Python or Perl is used, but then you're sacrificing speed. With Qt writing C++ is basically as easy as using Java, C# or any other 'modern' language. All of the nasty stuff is taken care of. For example, Qt code is generally cross-platform.

Its signal and slot system is also very powerful. For example, you connect a button's click() signal to the QApplication's quit() slot, and the button will cause the app to close when clicked. These signal/slot pairs can even be set via the Qt Creator IDE, just like Visual Basic! Or you might start up a webpage download and assign a slot to handle the signal sent when the page has been downloaded. Qt's signal/slots are introspective and modifiable at runtime, and you define new signals and slots just like you define new methods for a C++ class. The drawback there is that Qt programs require a pre-processing pass by moc (the meta-object compiler), in order to generate meta-data for runtime signal/slot manipulation, and to offer some syntactic sugar around Qt's features. As a side-effect, Qt adds syntactic sugar for features some might find questionable, for example adding a foreach() loop for lists.

The build system, qmake, is quite simple: you list your source files, libraries and headers to link in a short configuration file (qmake can even generate this for you). qmake then generates a makefile from this data. This is useful as it also includes the 'moc' pass, but can be constrictive in some cases. You are, of course, not obligated to use qmake in your Qt project.

As far as widgets go, Qt's are comparable with GTK or any other toolkit out there. Qt does a better job of looking good on non-Linux platforms, such as Windows. It has a simple but flexible widget system that is much easier to use than GridBagLayout or any of Swing's more poweful layouts.

The main issue with Qt was that, up until recently, it was licensed under the LGPL and before that, it was under the restrictive 'Qt license'. This is no longer the case, so jump in!

Re:I wonder about this

[umeboshi]

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.

Re:I wonder about this

[Eil]

There is a lot of software for the Nokia N810 and below. Switching out to a new UI means a lot of stuff will either get uprooted or there will be a lot of libraries loaded into the machine's precious little memory.

As it is, minor Maemo releases can (and sometimes do) break compatibility with applications while major releases are generally not expected to be backwards compatible at all. It works the same on any Linux distro or desktop environment. Development of Maemo has moved at a glacial pace, so when Nokia switches to Qt, I assure you it will be a major release.

I'm looking forward to Maemo on Qt 4 if for no other reason than it will make WebKit support a cinch. (The current official Maemo web browser uses Gecko and using it is generally an unpleasant experience.) In fact, if I recall correctly, there are some KDE folks trying to get KDE 4 ported to Maemo, with all the interface enhancements necessary to make it usable on small-screen devices.

Re:I wonder about this

[shutdown -p now]

You forgot one thing: performance. Qt guys take it very seriously, and have numerous tests showing off just how fast their rendering and layout code is. I would imagine that, for resource-constrained devices, this can be a big deal.

Re:I wonder about this

[shutdown -p now]

With VB you just click on the component (button etc) and it takes you directly to the code.

It would only do that for the "default" event of the component (e.g. Click in case of Button). To wire up other events - such as KeyDown or MouseMove - you still had to edit events in the property grid.

In reality, Qt signals/slots are exactly the same concept as VB events/handlers. "Default events" are a minor convenience feature, nothing more

I've never understood why other development environments have never taken the VB (or Delphi for that matter) route in GUI design.

Er, which ones didn't? WinForms is event-driven, and very similar to VB (down to the "double-click the button to auto-generate event handler for Click" you've described). WPF is broadly similar. Swing uses different terminology (listeners), but same concept. Really, it's one of the basic OO patterns, and most UI toolkits these days use it.

The thing that VB (and Delphi) truly lacked is the way to do dynamic layout of controls - this is absolutely crucial for DPI-independent and theme-independent code (you've got to be able to reflow the UI when font size changes, for example), and it simplifies localization a lot, as well. It's why all new (or just better) UI tookits - including Qt - are centered around the concept of dynamic automatic layouts; but at the same time, it's not something that you can easily edit visually (as has been demonstrated previously in case of HTML).

That said, Qt still lets you do absolute positioning of controls in a visual designer, if you really want to have it that way (shame on you!).

Re:I wonder about this

[StormReaver]

> The main issue with Qt was that, up until recently, it was licensed under the LGPL....

Slight correction: until recently, it was licensed under the GPL; but is now licensed under the LGPL.

Re:I wonder about this

[abigor]

Qt absolutely has bindings in other languages. For example, check out PyQt: http://www.riverbankcomputing.co.uk/news

Re:I wonder about this

[Kjella]

My main issue is that Qt is pretty strongly tied to C++, and I *despise* that language.

Did you try C++ with or without Qt? I must admit, I don't like C++ outside of Qt, it brings the whole platform to another level. QStrings and QByteArrays are a godsend compared to std::string and char *. Using the QObject system I easily write applications with no memory leaks because it will delete any child QObjects when it goes, making it easy even without amy garbage collector. Finally, using signals and slots makes your application more robust - screw something up and nothing will happen because the signal never reaches its destination but it won't crash hard on an invalid pointer. Granted, I've heard you can do the same with STL and boost and duct tape, but I never managed to do it.

Re:I wonder about this

[JudgeJackson]

The pattern is known as "Resource Acquisition is Initialization", or RAII. Search for that and you'll get a ton of hits. Simple rule of thumb: new in constructors, delete in destructors. There are smart pointer classes available to help you do this.Boost provides a set of them and it sounds like Qt has something similar.

Re:N900, please

[migla]

I think the RX-51, aka "N900" is due "second half of 2009". The OS for it will not be backwards compatible with the n800

For OS developments regarding n8*0, check out the community project "MER" instead: http://wiki.maemo.org/Mer_Blueprint

Qt != KDE, GTK+ != GNOME

[Anonymous Coward]

It seems like they're still planning on using a lot of GNOME components, but putting a Qt skin on it. I just wonder if it is the best of both worlds, or the worst of both worlds...

Re:Starting over

[glebovitz]

take a look at the new animation framework, state machine, and the declarative UI if you want to see good reasons why they are making the switch.

Nokia owns Qt.

[Futurepower(R)]

Before you read too far, realize that Nokia owns Qt. It is not surprising that Nokia products use Qt.

Re:Nokia owns Qt.

[PiSkyHi]

Above post should be modded "-1 trolltech"

GNOME just need to die

[metamatic]

With the Mono infection and the reliance on GTK, the best thing would be for GNOME to go away. It started because Qt wasn't LGPL. That no longer applies, so let it die.

Re:This is the Death of Maemo,if it really ever li

[chill]

...except at least they were attemping to make a useful device from day one, while Nokia has totally let that ship sail into Apple's hands.

Is that Kool-Aid good?

Nokia sells 4x more smartphones than Apple does, with over 40% of the worldwide market. Nokia has won more design awards for phones than Apple, by a long shot. They even have smartphones (n97) that handily beat the iPhone. The problem is, Nokia caters to users NOT phone companies and thus the North American carriers don't sell their smartphones. All you can really get in the U.S. is their standard phones.

They're trying to get a bigger presence in the U.S. market, and are examining how to leverage QT, Symbian and Linux in doing that. At least they aren't sitting on their collective asses (like Motorola) and getting crushed.

Don't write them off.

http://money.cnn.com/2009/01/12/technology/hempel_nokia.fortune/
http://news.cnet.com/8301-13579_3-10245339-37.html
http://www.nokiausa.com/find-products/phones/nokia-n97/specifications

Gtk+ is not Nokia's problem

[jipn4]

Nokia has its own lightweight GUI library that they use with Symbian--and their UIs suck. They have built applications with Gtk+--and their UIs suck. They have build Windows and OS X desktop apps--and their UIs still suck. I think the problem Nokia has with GUIs and software has to do with how they develop software, not whether they use Gtk+ or Qt.

Another problem with their choice is that it ties them to C++; the trend in mobile development, however, is towards other languages, like Javascript (Pre), Java (Android), Objective-C (iPhone), and C# (Windows Mobile). Only Symbian steadfastly clings to C and C++. That would be fine if Symbian actually ended up being the fastest and having the best UI of the bunch, but it's actually the slowest and least responsive of the bunch.

Re:Gtk+ is not Nokia's problem

[ultrabot]

No, they won't. C++ is fast for small inner loops because programmers there can take full advantage of its features. Big applications end up being slow and bloated in C++ because programmers simply cannot manage the complexity anymore: all their time goes into chasing pointer bugs and dealing with include files, and little remains for performance tuning and algorithms.

That's bollocks. C++ is not really that much less productive than Java/C# if you have a good platform toolkit to go with it (Qt). With Qt, you don't really manage your memory manually most of the time, the classes do it themselves through implicit sharing.

Admittedly, C++ is much less productive than Python & other dynamic languages, but that's not the issue at table here; we are comparing against Java, C#, ObjC.

And what is this "long run" you're speaking of anyway? If it takes 5 years for Nokia to optimize their current C++ applications, do you think anybody will care?

The phone applications easily have a life span of several years. They get improved, but rarely rewritten.

This applies even more so to "platform" level stuff. If you write more of that in C++ than Java, you'll have a faster platform, given equivalent algorithms.

There is no "in the long run" for software; what counts is what you can deliver in 3-6 months, not in a few years.

It seems Nokia was able to turn a profit with Symbian, even if Symbian is widely dreaded as the least productive programming environment in existence. I believe they will do great with Qt, and attract a great deal of third party interest as well.

Qt uses only 'nice' parts of C++

[chris-chittleborough]

The Qt designers don't just create widgets etc, they design components that are easy to program with. As part of this, they avoid stuff that requires the tricky/ugly parts of C++. For instance, you rarely need to explicitly delete objects, because their libraries use reference counting to automagically delete objects at the earliest appropriate time.

So it is easy for any good programmer to learn enough C++ to use Qt effectively.

(Actually, Qt uses an extended version of C++, implemented via a preprocessor. The extensions provide "signals" (like no-op methods) and "slots" (methods which can be connected to signals), plus a limited-and-very-useful facility for run-time widget class information. As usual with Qt, these facilities are just extensive enough make it easy to do the things most people want to do, rather than trying to provide everything that anyone might want.)