Linked by Thom Holwerda on Mon 6th Jul 2009 15:43 UTC
Qt 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.
Order by: Score:
v really ?
by el barto on Mon 6th Jul 2009 15:53 UTC
RE: really ?
by wanderingk88 on Mon 6th Jul 2009 16:42 UTC in reply to "really ?"
wanderingk88 Member since:
2008-06-26

KDE technologies have nothing to do with Qt. KDE is built on Qt but Qt is an independent technology of its own.

Reply Score: 4

RE: really ?
by protomank on Mon 6th Jul 2009 17:19 UTC in reply to "really ?"
protomank Member since:
2006-08-03

"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

Reply Score: 3

v News?
by andy_js on Mon 6th Jul 2009 15:57 UTC
RE: News?
by KAMiKAZOW on Mon 6th Jul 2009 20:55 UTC in reply to "News?"
KAMiKAZOW Member since:
2005-07-06

It was announced that Qt will be included, but not that the GUI will be rewritten in Qt.

Reply Score: 3

Comment by Mark Williamson
by Mark Williamson on Mon 6th Jul 2009 15:59 UTC
Mark Williamson
Member since:
2005-07-06

<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 ...

Reply Score: 8

RE: Comment by Mark Williamson
by boldingd on Mon 6th Jul 2009 16:05 UTC in reply to "Comment by Mark Williamson"
boldingd Member since:
2009-02-19

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.

Reply Score: 4

RE[2]: Comment by Mark Williamson
by flynn on Mon 6th Jul 2009 17:14 UTC in reply to "RE: Comment by Mark Williamson"
flynn Member since:
2009-03-19

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.

Reply Score: 5

RE[2]: Comment by Mark Williamson
by Elv13 on Mon 6th Jul 2009 17:53 UTC in reply to "RE: Comment by Mark Williamson"
Elv13 Member since:
2006-06-12

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.

Reply Score: 2

vivainio Member since:
2008-12-26

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

Reply Score: 6

RE: Comment by Mark Williamson
by TemporalBeing on Mon 6th Jul 2009 18:10 UTC in reply to "Comment by Mark Williamson"
TemporalBeing Member since:
2007-08-22

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.

Reply Score: 4

"Gnome" stack in harmattan
by vivainio on Mon 6th Jul 2009 18:37 UTC in reply to "RE: Comment by Mark Williamson"
vivainio Member since:
2008-12-26

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


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.

Reply Score: 6

RE: "Gnome" stack in harmattan
by TemporalBeing on Mon 6th Jul 2009 23:59 UTC in reply to ""Gnome" stack in harmattan"
TemporalBeing Member since:
2007-08-22

"True...my guess though is that they will eventually push away from GNOME and are using this as a stepping stone.


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.
"

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.)

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.


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.

Reply Score: 4

RE: Comment by Mark Williamson
by Daniel Borgmann on Mon 6th Jul 2009 20:26 UTC in reply to "Comment by Mark Williamson"
Daniel Borgmann Member since:
2005-07-08

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.

Reply Score: 3

Not Surprised
by segedunum on Mon 6th Jul 2009 16:07 UTC
segedunum
Member since:
2005-07-06

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

Reply Score: 5

good
by poundsmack on Mon 6th Jul 2009 16:12 UTC
poundsmack
Member since:
2005-07-13

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.

Reply Score: 6

RE: good
by KAMiKAZOW on Mon 6th Jul 2009 20:20 UTC in reply to "good"
KAMiKAZOW Member since:
2005-07-06

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.

Reply Score: 3

not surprising
by JoeBuck on Mon 6th Jul 2009 16:55 UTC
JoeBuck
Member since:
2006-01-11

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.

Reply Score: 5

RE: not surprising
by arpan on Mon 6th Jul 2009 17:43 UTC in reply to "not surprising"
arpan Member since:
2006-07-30

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.

Reply Score: 6

RE[2]: not surprising
by reez on Tue 7th Jul 2009 14:18 UTC in reply to "RE: not surprising"
reez Member since:
2006-06-28

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.

Reply Score: 1

RE: not surprising
by lpotter on Wed 8th Jul 2009 07:21 UTC in reply to "not surprising"
lpotter Member since:
2005-12-01

Nokia purchasing Trolltech was all about technical merit. It certainly wasn't because Trolltech was making heaps of money.

Reply Score: 4

Comment by Maki
by Maki on Mon 6th Jul 2009 16:59 UTC
Maki
Member since:
2009-06-28

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

Reply Score: 5

RE: Comment by Maki
by Hiev on Mon 6th Jul 2009 17:25 UTC in reply to "Comment by Maki"
Hiev Member since:
2005-09-27

Since the 100% of those technologies were initially developed by GNOME developers, is not that wrong.

Edited 2009-07-06 17:37 UTC

Reply Score: 1

RE[2]: Comment by Maki
by KAMiKAZOW on Mon 6th Jul 2009 20:07 UTC in reply to "RE: Comment by Maki"
KAMiKAZOW Member since:
2005-07-06

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-...

Reply Score: 6

RE[2]: Comment by Maki
by segedunum on Tue 7th Jul 2009 19:02 UTC in reply to "RE: Comment by Maki"
segedunum Member since:
2005-07-06

Since the 100% of those technologies were initially developed by GNOME developers

We can only hope that one of these days you will start having a clue what you're commenting on. Vain hope.

Reply Score: 6

Expected ...
by dindin on Mon 6th Jul 2009 19:58 UTC
dindin
Member since:
2006-03-29

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.

Reply Score: 3

RE: Expected ...
by flynn on Mon 6th Jul 2009 20:15 UTC in reply to "Expected ..."
flynn Member since:
2009-03-19


Notably, VLC changed away from Gtk.

I don't think VLC ever had a Gtk interface. Before they moved to Qt they used wxWidgets.

Reply Score: 2

RE[2]: Expected ...
by dindin on Mon 6th Jul 2009 20:24 UTC in reply to "RE: Expected ..."
dindin Member since:
2006-03-29

Before they moved to Qt they used wxWidgets

Yes. But wxWidget used the wxGtk backend which relied on Gtk - atleast on Linux/BSD.

Reply Score: 2

RE[3]: Expected ...
by bnolsen on Mon 6th Jul 2009 21:56 UTC in reply to "RE[2]: Expected ..."
bnolsen Member since:
2006-01-06

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.

Reply Score: 4

Dumping X11
by IkeKrull on Mon 6th Jul 2009 20:46 UTC
IkeKrull
Member since:
2006-01-24

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.

Reply Score: 6

RE: Dumping X11
by vivainio on Mon 6th Jul 2009 21:01 UTC in reply to "Dumping X11"
vivainio Member since:
2008-12-26

I think the primary motivation is to dump the requirement for an X Server on these devices.


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.

Reply Score: 3

RE[2]: Dumping X11
by bnolsen on Mon 6th Jul 2009 22:03 UTC in reply to "RE: Dumping X11"
bnolsen Member since:
2006-01-06

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.

Reply Score: 2

wahoo.. no more non-native KeepassX
by jabbotts on Mon 6th Jul 2009 21:44 UTC
jabbotts
Member since:
2007-09-06

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.

Reply Score: 2

jabbotts
Member since:
2007-09-06

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)

Reply Score: 2