OSNews

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

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

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.

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



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.

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.

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.

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.

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.

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.