As some had already anticipated when Nokia acquired Trolltech, the next version of the Maemo platform will have its application framework based on Qt instead of Gtk+. This news was announced at the Gran Canaria Desktop Summit. While the switch to Qt may seem a major defeat for the GNOME community, this isn’t exactly true, as many of the underlying technologies will still be GNOME-centric.
Basically, the main toolkit for the Maemo platform will become Qt instead of Gtk+, with Gtk+ becoming a community maintained part of Maemo. However, all of the underlying technologies will still be GNOME-centric, such as glib, dbus, gvfs, bluez, telepathy, avahi, gstreamer, gconf, and so on.
The news was announced by Maemo/Nokia Open Source Marketing Manager Quim Gil during his keynote at the Gran Canaria Desktop Summit. “Maemo Harmattan will base its application framework in Qt while keeping most of the Fremantle middleware based on GNOME technologies,” he writes on his blog, “The goal is to offer an open, efficient and compelling Linux mobile stack with a cross-platform Qt API used also by Symbian and available in other mobile and traditional operating systems.”
GNOME developer Vincent Untz also writes about the change on his blog. “So while the move to Qt is a logical move from Nokia, it’s good to see that Nokia stays firmly committed to GNOME Mobile. It’s actually quite amazing to see that what we built there is attractive to a big industry player like Nokia (and, well, a bunch of other players).”
The first devices based on the new Maemo platform are still a while off, as this year’s Nokia N900 (a rumoured device) is still supposed to be based on Gtk+.
“as many of the underlying technollogies will still be GNOME-centric.”
really?, kde use dcop so gnome take dcop and raname to dbus and viola, gnome technollogie. what about Kio?
KDE technologies have nothing to do with Qt. KDE is built on Qt but Qt is an independent technology of its own.
“really?, kde use dcop so gnome take dcop and raname to dbus and viola, gnome technollogie. what about Kio?”
– KDE is not the same as Qt
– KDE4 uses dbus and droped dcop
– dbus and dcop are very different, other than having the same purposes
– again, kio slaves are KDE, and not Qt, technology
I’m pretty sure this was announced ages ago. If not, it was fairly obvious it was going to happen.
Damn you QT!
It was announced that Qt will be included, but not that the GUI will be rewritten in Qt.
<quote>glib, dbus, gvfs, bluez, telepathy, avahi, gstreamer, gconf</quote>
Out of those, surely at least dbus, telepathy, avahi and bluez are all desktop-neutral? Did that perhaps mean to say Gnome-compatible or *even* “developed by Gnome people”, as opposed to Gnome-centric? Because they are things that can be / are used by other desktop environments too …
I’m trying to figure out why you’d use glib, or what you’d use it for, if you’re mainly writing software in C++ on QT. My understanding was that glib mainly provided an object system for C: C++ has its own, different object system already.
GObject is just one part of glib. The library also offers other things such as data structures and utility functions for all sorts of things. However, QtCore offers largely the same things.
GLib is an optional dependency of Qt. I think Qt can share even loop and some other part with glib so only one will run in the background and be loaded in memory, even if both Qt/KDE and Gnome apps are used at the same time.
Yes, Qt can (and does) use the glib event loop. This is a big deal, since it means you can use libs from gnome/glib crew that interact with the event loop (register timeouts, use dbus, poll on sockets…) without modifications.
Conserving memory is besides the point.
It might be cool to factor the event loop out from the rest of the glib, and establish it as a lean “Unix event loop” :-). Rest of the glib is pretty pointless when you have QtCore around.
Incidentally, I’d like too QtCore & C++ pushed forward in Linux userspace “core” development much more now that it’s LGPL, instead of being systematically shot down in favor of glib; see
http://lists.kde.org/?l=kde-core-devel&m=124656875804833&w=2
True…my guess though is that they will eventually push away from GNOME and are using this as a stepping stone. The whole:
1) Add new stack with compatibility for the old
2) Start deprecating the old stack
3) Remove the old stack and be completely on the new
Qt is great; and has a lot of advantages – signals/slots is one that is far superior to Message Maps (Gtk, MFC). It also plugs in easily with other toolkits (Gtk, Win32, Cocoa) and can use other signal/slot implementations (e.g. Boost) either out-right or in parallel, and can switch out its message loop too if desired.
Any how…that’s my guess.
They have very little reason to throw away the “Gnome” stack, because it’s pretty much the standard Linux stack these days. Having it around allows them to leverage the work of others, and contribute back to Linux.
Also, a lot of that stack is just a bunch of daemons. It’s not like you have to be married to Gnome to benefit from it. They “just work” in the background.
Ironically, even if dbus is often (misguidedly) pushed as “Gnome” technology, it’s Qt that has the world-class dbus bindings (QtDbus). This is good, considering that dbus is at the heart of what is happening in Linux userspace these days.
Well…what’s common enough for Qt/Gnome/KDE to work together is not exactly GNOME specific, so I would hardly call that part of the GNOME stack – and that’s really what is standard these days, not necessarily anything specific to GNOME. For instance, you don’t need anything GNOME related installed to run KDE or any number of other Windows Managers – or Qt for that matter.
And if there’s nothing GNOME specific, then why keep it around? Qt offers a lot of stuff (QStrings, QtDbus [as you point out], etc.) that are just so much easier to work with – and if you don’t have to move between two toolkits, why do so?
Why make an SDK that has to support two toolkits, when using one gets you all you need and still maintains the compatibility? Qt does just that; so why keep around any GNOME-specific stuff in the long run? (Thus my original comment.)
I’m not sure I’ve ever heard of D-Bus as being GNOME technology until this thread – I certainly wouldn’t consider it so. I hear a lot more about it from KDE stuff as they use it extensively, and also FreeDesktop.org related stuff.
And this is how it should be. Developing software for ego is pointless, software is developed for usefulness. It doesn’t matter one bit how “GNOME centric” a library is, what matters is that these are all technologies that together build the foundation of what is known as “the GNOME project”. “GNOME” isn’t just a bunch of people or corporations who strife for personal recognition, it’s a rallying flag for many diverse (but interoperable) free software desktop technologies.
I’m not really surprised. Maemo, Gnome Mobile and Hildon just haven’t made as much progress as they should have done over the years. Gnome/GTK 3 isn’t on the horizon yet to provide essentials such as resolution independence and third-party application development isn’t up to scratch either.
While the slide about Nokia continuing to be a Gnome contributor is nice and the ‘politically correct’ thing to do, I fail to see how they’ll be able to continue using some of the components that they are (glib with C++?) and moving to Qt has been a protrected affair in itself. I don’t give two straws about them using PulseAudio on such a platform.
Edited 2009-07-06 16:08 UTC
While this might add a bit more time to development, I ultimatly believe this will benefit the platform as a whole. QT seems to me like more of a future ready tool kit, while GTK (in the last year or so) seems like the code base is getting a bit cluttered. Just personal opinion of course, but I made the switch from GTK2 to QT a few years back and I haven’t looked back. Good luck Maemo team.
Well, GUI-wise MIDs and smartphones are not that different. Qt already ran on cell phones before Maemo even started.
Even if we completely ignore the fact that Qt integrates better into non-X11 desktop platforms (Win and Mac OS X), in the handheld space alone Qt is the more portable alternative. It runs on Windows Mobile, Linux and Symbian S60.
No matter which OS upcoming Nokia devices are based on, Nokia can just use Qt for their apps.
Third party handheld app developers can also just use Qt and target probably ~80% of all handhelds worldwide — no matter if they were bade by Nokia or whoever.
Nokia owns Qt, so they ordered everyone to use Qt. Similarly, when Microsoft buys a web services firm that uses a LAMP stack, they make them switch to Microsoft technology. In neither case are the decisions made on technical merit (not that there’s anything wrong with Qt, it is a well-designed library).
However, I agree with the other commenters that the alleged “Gnome-centric” technology is actually desktop-neutral technology coming from freedesktop.org and used both by KDE and Gnome.
On the other hand, there was a reason Nokia purchased QT. If they were satisfied with GTK, they would have continued using that and never purchased Trolltech & QT.
I guess they purchased Trolltech (the company, not the library!) because they had potential to offer a better mobile platform than they do.
Most companies purchase potential, small enemies before they get big enemies. The technology is a nice extra (or the reason for being a danger), but I doubt Trolltech was purchased to aquire the technology in first place.
Nokia purchasing Trolltech was all about technical merit. It certainly wasn’t because Trolltech was making heaps of money.
I don’t see how the fact that maemo will still use freedesktop standards makes it gnome centric, since kde also uses them.
Also being qt based doesn’t make it KDE based. Nokia aquired trolltech and it is easier for them to eat their own dog food, there is no conspiracy or something like that
Since the 100% of those technologies were initially developed by GNOME developers, is not that wrong.
Edited 2009-07-06 17:37 UTC
Huh? BlueZ was developed by Qualcomm annd is part of the Linux kernel. It has no special relationship with GNOME. Whith the exception of GLib, none of the listed technologies have any special relationship to GNOME. Just because a neutral technology was first implemented in GNOME doesn’t turn it into “GNOME-centric”. E.g. D-BUS: It was GNOME was the first to officially embrace it, but GNOME also had more to gain by it, because Bonobo seems to have bigger defiencies than DCOP had (at least according to IBM): “DCOP is a solution for KDE, but is tied to Qt and so is not used in other desktop environments. Similarly, Bonobo is a solution for GNOME, but is quite heavy, being based on CORBA. It is also tied to GObject, so it is not used outside of GNOME. D-BUS aims to replace DCOP and Bonobo for simple IPC and to integrate these two desktop environments. Because the dependencies for D-BUS are kept as small as possible, other applications that would like to use D-BUS don’t have to worry about bloating dependencies.” http://www.ibm.com/developerworks/linux/library/l-dbus.html?ca=dgr-…
We can only hope that one of these days you will start having a clue what you’re commenting on. Vain hope.
This is not all that unexpected.
Something like this was coming. Gtk has had cross platform issues not that this was the reason for the Nokia shift. Does Gtk work on OS -X yet?
Notably, VLC changed away from Gtk. I heard that Wireshark developers were also thinking of this for the GUI frontend.
I don’t think VLC ever had a Gtk interface. Before they moved to Qt they used wxWidgets.
Before they moved to Qt they used wxWidgets
Yes. But wxWidget used the wxGtk backend which relied on Gtk – atleast on Linux/BSD.
Umm…wxWidgets is a cross platform wrapper that backends into native widgets. GTK is just one target (that’s totally abstracted out). It’s absolutely not the same as using GTK.
I think the primary motivation is to dump the requirement for an X Server on these devices.
GTK+ just isn’t supported well on anything but X11, while Qt will render into a raw framebuffer quite happily. This means faster startup, lower memory footprint, a way more cohesive ‘application management’ environment and no need for separate-process window managers etc.
Providing proprietary accelerated rendering support for specific QT Widgets is also going to be much easier when there is no X Server between Qt and the hardware, which may be something Nokia wants to implement.
Nah, Gtk+ is probably still going to be there (supported by community, as the slides say). Dumping X would seriously divorce them from Linux community at large, and Maemo (unlike Android) still tries to be reasonably “standard” Linux platform. It’s a competitive advantage.
I seriously doubt this to be a problem.
As long as one uses QT calls only this should be by and large irrelevant. Worst case the application is developed on the platform of choice using a preset geometry and cross compiled/ported to the target platform with minimal effort.
That seems to be one of the goals here.
It’ll be nice to have full support for the KeepassX functions. It’s great for a reference source but the copy/past function is missed when dealing with 20 char random passwords.
The current issue is that you need add the axtra QT support for QT apps. Will the maemo community have to port apps over to QT or will there be a gtk compatability in place also. Maemo has a nice and growing library in the repositories already, some of it I don’t know if I could part with.
(Also like to see native cal/todo/notes/addrs pim app with better sync than the gepsynd+opensync+syncML process to support my eGroupware)