Maemo moving to Qt
At the Gran Canaria Desktop Summit (GCDS) on July 4th, Nokia's Maemo marketing manager Quim Gil announced that, beginning with the Harmattan release expected in 2010, the company would adopt the Qt toolkit for Maemo's application and user interface layer, replacing the Hildon user interface and GTK components that have served that function since the platform's debut. The announcement was met by a mixed reaction from the Maemo development community, which is already faced with significant API incompatibilities scheduled for the still-to-come Fremantle release, but most agreed that the move was inevitable in light of Nokia's acquisition of Qt creator Trolltech.
Gil presented his talk during the combined GNOME and KDE portion of GCDS, starting with an overview of the current Maemo platform and explaining the upcoming changes in Fremantle before addressing the move towards Qt. "Fremantle" is the code name for Maemo 5.0, and although the software development kit (SDK) has been released, the software and the new hardware devices on which it will run have not. Fremantle will retain many of the same components on which earlier Maemo devices were built, but also introduces some new ones, including the PulseAudio sound server, an X.org X Window implementation, and the Upstart init replacement.
Fremantle will also support a community-maintained Qt toolkit, but the Maemo environment and Nokia applications will remain on GTK and Hildon. Starting with Harmattan, Gil explained, the GTK/Hildon and Qt frameworks will swap places: the core applications and interface will be written for Qt, and GTK/Hildon will be supported through a community-maintained stack. He went on to explain that Nokia will continue to use and contribute to numerous middleware components from the GNOME stack that have always been pieces of Maemo — including GConf, GVFS, and GLib, among others — and emphasized that the move to Qt would bring Maemo a step closer to being a traditional Linux platform, rather than a partially-compatible, niche variant.
Regarding the decision to move from GTK/Hildon to Qt, Gil's talk cited two factors. First, the Qt framework is available on desktop systems and handheld devices like Symbian-powered phones, making it easier for application developers to use one tool chain and one API across a variety of platforms (although GTK is available on desktop systems, Hildon is designed for mobile devices). Second, Nokia plans on furthering development of the Qt toolkit through its QtMobility project, which will develop entirely new APIs for mobile devices running Symbian, Maemo, or Windows CE.
Developer reaction
Responses to Nokia's announcement hit Maemo-related blogs and discussion boards almost immediately. Some expressed optimism about the switch, but many more expressed their reservations — not about Qt itself, but about the sudden switch from one toolkit to another, and the accompanying switch from C to C++ as the core language. In the Maemo Talk forum thread discussing the announcement, several posters expressed concern that neither Fremantle nor Harmattan would officially support both the old and the new toolkit, thus leaving third-party developers without a smooth transition plan.
Furthermore, the difficulty of the toolkit switch between Fremantle and
Harmattan is compounded by the fact that Fremantle will break compatibility
with the Maemo 4.x-series, thus forcing two consecutive rewrites onto
developers. Others in the thread questioned the timing of the
announcement, since Fremantle has yet to be released. According
to forum member "pycage", "This story gives me the impression that
Fremantle, from a developer's point of view, is already obsolete even
before it was released.
"
Murray Cumming of embedded Linux company Openismus observed
on his blog "its clearly a rather arbitrary and disruptive
decision. I suspect that some managers are dictating the Nokia-wide use of
Qt even in projects that dont 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 [...]
"
Gil, however, defended the move to forum members, noting
that "providing commercial support on both frameworks [GTK/Hildon and
Qt] for both releases [Fremantle and Harmattan] implies an amount of work
that we simply can't nor want to commit [to].
" He responded
to developers' fears of two consecutive releases breaking compatibility by
assuring them that the transition would be smooth because of the consistent
middleware layer, and noted that the advance timing of the announcement
itself was an effort to give early warning so that developers could have
adequate time to prepare. He also said
that it was too early to draw conclusions about compatibility across
releases, since many of the details of Harmattan are still unknown.
Nokia and Qt ... and Symbian
Uncertainty about transitioning between two user interface toolkits aside, no one seemed surprised by the announcement that Maemo would move to Qt, given that Nokia acquired Trolltech — subsequently renamed Qt Software — in January of 2008. As Gil alluded, moving Maemo to Qt allows Nokia to more efficiently repurpose its engineering resources toward the development of a single software stack. More importantly, however, by using Qt on Maemo Nokia will be "eating its own dogfood," and can thus more actively promote Qt as a commercial solution to application developers.
Several in the community noted that, in the market for Qt, Maemo is considerably smaller than desktop Linux, which itself is considerably smaller than the smartphone operating system Symbian, which Nokia acquired in June of 2008. Shortly after the acquisition, Nokia announced plans to release Symbian as open source software, and set up the Symbian Foundation to manage the code. The company released its first preview of Qt running on top of Symbian in October of that year, and has continued to develop it as a "technology preview," highlighting its cross-platform capabilities.
Maemo Talk forum member "eiffel" speculated that Nokia's plan might be to somehow merge Maemo and Symbian into a single OS, but Gil's talk presented a more straightforward plan: he described Maemo as the platform best suited to high-end mobile hardware like mobile Internet devices (MID), occupying the middle slot in between Symbian-powered phones and full Linux desktops. Maemo bloggers Daniel Gentleman and Jamie Bennett both observed that by acquiring Qt and Symbian, Nokia was better positioning itself to compete against the full range of handheld devices that are soon expected to be running Android.
Gil commented in the Maemo Talk discussion that Nokia plans to develop
new Qt APIs specific to handheld devices under the QtMobility project. The
QtMobility site lists three new APIs: connections
management, contacts,
and a service
framework. Source code for all three is available from a public Git
repository, although none have yet been bundled for stable release. Gil indicated
that the new APIs will be shared across the platforms, but that Maemo and
Symbian will not share other code. "The interest is to align on the
API level. Then each platform will push its own identity and strengths
based on the target users and form factors of the products released. This
means that UI and pre-installed application might differ, and in some cases
even significantly.
"
What's next?
Moving Maemo from GTK/Hildon to Qt may be painful in the short term — at least for some developers — but the long term benefits of a single toolkit for both Linux-based and Symbian-based platforms no doubt made the decision easy for Nokia. The big question remains — regardless of whether it uses GTK/Hildon or Qt — where does Nokia intend to take Maemo itself? The platform has plenty of fans in the open source community, but it remains a niche OS.
Since its debut, Maemo has shipped on only three Nokia devices: the 770, N800, and N810 Internet Tablets, the last of which was launched in 2007. Although a community effort exists to extend the platform's hardware support, and it can run on a BeagleBoard development motherboard, to date no non-Nokia consumer product has ever adopted Maemo as its operating system. Fremantle will reportedly launch on a new generation of device, running on OMAP3-based hardware that Nokia notably does not refer to as an Internet Tablet like its predecessors, opting instead to use generic terminology like "device" and "hardware."
It would require considerable reading between the lines to speculate that Nokia intends to ship Maemo on its high-end smartphones, especially considering that the company has continued to push Symbian as its platform of choice for its high-end N-series and E-series phones four years after launching Maemo. But unless Nokia plans to offer more products in the MID product category, it does seem strange to expend resources maintaining an entire operating system for a single device, especially while touting the multi-platform reach of Qt as one of its strengths.
Index entries for this article | |
---|---|
GuestArticles | Willis, Nathan |
Posted Jul 16, 2009 4:00 UTC (Thu)
by salimma (subscriber, #34460)
[Link]
Now, if they'd push for open-sourcing hardware drivers too ...
Posted Jul 16, 2009 10:14 UTC (Thu)
by guus (subscriber, #41608)
[Link] (5 responses)
This is a bit of a red herring. I personally like GTK, but only if I can write in C++, Python or other object-oriented language.
The plain C interface to GTK is just horrible, even when using libglade.
And C++ doesn't force its features on C coders, they can write as they used to write, and only need to use C++ features when using Qt objects.
Posted Jul 16, 2009 18:31 UTC (Thu)
by tstover (guest, #56283)
[Link] (4 responses)
I also would not recommend libglade or gtkbuilder.
Qt is not really C++ anyway, it's c++ and a macro language. (which in and of itself illustrates some of the limitation of C++ in the first place)
...and yes I am a C fanboy
Posted Jul 22, 2009 0:44 UTC (Wed)
by Tronic (guest, #59702)
[Link] (3 responses)
Today it is a different situation. With some magic of templates one can
From a developer point of view, GTKmm is by far the nicest GUI library to
Posted Jul 22, 2009 8:17 UTC (Wed)
by halla (subscriber, #14185)
[Link]
Er, no. GTKmm is merely is the nicest gui library from your personal point of view, not from the
developer point of view. It is only your opinion, not a general truth. Other people find Qt much,
much nicer -- and that is their opinion. Some people express that opinion rather well, like
Guillaume does in http://www.telegraph-road.org/writings/gtkmm_vs_qt.html.
Personally, I think that that the Qt-is-not-C++ meme is pure nonsense caused by prejudice.
If it weren't C++, my C++ compiler couldn't compile it. It can, so it is. Whether or not you like its
use of generated macros and generated C++ is your opinion, but it doesn't change the language at
all. They are convenient, and in about ten years of Qt coding, they haven't hindered me when
debugging at all. The introspection and runtime flexibility it gives me is very valuable.
And one real fact is that people using Qt are very productive. That's easily proven by seeing all
the things that are produced using Qt.
Posted Jul 23, 2009 15:38 UTC (Thu)
by robert_s (subscriber, #42402)
[Link] (1 responses)
This is total nonsense. It is fully compliant C++. It just has a class autogenerator. Similar to how you can get glade etc. to autogenerate code for you.
"With some magic of templates one can implement really nice signal handling that is safer and a lot less intrusive than Qt's MOC/QObject-based system."
I would like to see something other than fanboyism here.
Posted Jul 24, 2009 8:25 UTC (Fri)
by amigadave (guest, #59782)
[Link]
Glade 3 does not autogenerate code, but Glade 2 did (I do not know about Glade 1). Glade 3 will only generate an XML description of your user interface, which you can load with either libglade or GtkBuilder.
With regards to your other comments (and similar ones, in this thread), I think that when most people say "Qt is not C++" they intend to say "Qt without moc is not C++", which is valid -- one cannot compile the majority of Qt-using code without moc. The moc-generated code is nothing to be particularly worried about, except that some people do not like the dependence on a second preprocessor. It is also true that with some "clever" C++, nearly everything that moc accomplishes can be done without the use of macros or a second preprocessor.
I use both Gtkmm and Qt at work, and find that both have their advantages and disadvantages -- there is no clear winner. Currently, the support of Qt on Maemo is not that great, in my experience, so it will be interesting to see the new APIs that become available with the Harmattan release. I look forward to an improvement over the Hildon C APIs, but time will tell.
Posted Jul 23, 2009 6:18 UTC (Thu)
by pasitron (guest, #59751)
[Link]
Posted Jul 23, 2009 18:48 UTC (Thu)
by KGranade (guest, #56052)
[Link] (1 responses)
"making it easier for application developers to use one tool chain and one API across a variety of platforms"
"...QtMobility project, which will develop entirely new APIs for mobile devices running Symbian, Maemo, or Windows CE."
So first you get the mobile developers to migrate to a set of APIs that are shared with desktop platforms, and then you get them to migrate to ANOTHER mobile-only API set? Perhaps the QtMobility APIs will be somehow compatible, but if so that should be made clear.
Posted Jul 23, 2009 19:44 UTC (Thu)
by halla (subscriber, #14185)
[Link]
Maemo moving to Qt
Maemo moving to Qt
Likewise, hundreds of C coders cannot become capable C++ coders overnight.
Maemo moving to Qt
Maemo moving to Qt
reason. Trolltech deliberately chose not to use many C++ features in favor
of better portability and I have to agree: that did make sense in the late
90's when C++ was just being standardized and when the compilers were
nowhere near supporting it properly.
implement really nice signal handling that is safer and a lot less
intrusive than Qt's MOC/QObject-based system. SigC++ of GLibmm and
Boost.Signals are the best known implementations and both have very similar
features. Both can use each-other's "signals" just fine because any regular
function or functor of the right form works.
work with. It is elegant, it gets the job done with no extra boilerplate
and it doesn't leak memory or segfault (nor use pointers, what a
coincidence) in your everyday GUI stuff. It's a shame really that it
doesn't offer native UI on Windows or Mac and thus using it is really not
an option for cross-platform software.
Maemo moving to Qt
Maemo moving to Qt
Maemo moving to Qt
Maemo moving to Qt
Maemo moving to Qt
Er... Maybe the mobility apis are a sort of, you know, add-on, instead of
a replacement? So, you've got what Qt offers (strings, data structures,
push buttons, xml, threading, networking, concurrency, styling, whatever),
and then you get additional finger-food widgets, addressbook, geolocation
etc. api's. Sort of complementary, but all designed with the same
fastidious api principles so the principle of least surprise holds
through the sdk.
Maemo moving to Qt