Submitted by Thiago Macieira says in his blog: “With commit 546830, KDE says good-bye to one of its longest friends: DCOP. The technology has served us well for 6 years, to the point that has become one of our most proeminent features.” From now on, the KDE 4 tree will use DBUS. Due to the very extensive use of DCOP in KDE, this is a big jump for DBUS, “probably bring[ing] more applications into D-BUS in one go than there currently are”.
the pissing constests here on this site, about which is better, DCOP or D-BUS… KDE said the final word.
At least this zealoting theme is gone now. I think it is appropriate to wave goodbye to this theme and say “so long and thanks for all the fishes”
Edited 2006-05-31 18:24
…And a massive shot in the arm for freedesktop.org and increased desktop interoperability.
Well done Kde devs – I applaud your sensible decision and commitment to better desktop interoperability.
I have full confidence in Gnomers and KDE’ers working in tandem to make Linux on the desktop a more viable reality.
Good stuff, good stuff. This opens up all sorts of avenues; it’ll make Solid development easier (thanks to one removed layer of abstraction for hotplugging), and just think of all the universal media player controller software people will start writing! oh boy! Not only that, but it just makes things more standard, which is perhaps the most important thing.
I really like the KDE philosophy of exposing all sorts of interfaces to a system message bus. I’m surprised GNOME programs don’t adopt that as much; it would seem to me to be a GNOME-y way of doing things.
(GNOME is my desktop of choice, by the way, but I might just switch when KDE 4 becomes usable.)
This doesn’t remove a layer in regards to hotplugging. DBUS and DCOP are both messaging protocols, replacing one with the other doesn’t eliminate a layer.
For KDE users, this change will probably not have an difference to the end user.
Although I haven’t looked at it yet, it hope DBUS is as easy to use as DCOP was/is. It was amazing how even the most unexperienced users could easily look at the possible messages an app used and could be sending messages from a simple BASH script with minimal programming experience.
I am sure DCOP is easy to use. If it wasn’t I don’t think the KDE devs would switch. From some posts I have read at dot.kde.org it appears that the general concept of DBUS is actually based on DCOP.
DBUS was written as a *simple* messaging framework and integrated in gnome. It grew and matured along with gnome and is replacing the overengineered bonobo IPC mechanism.
KDE adopted dbus because it is well designed, clean, and easy to use. I’m not saying DCOP is or isn’t any of those either. However, standardization will propel open source forward at a faster rate.
Developers on both sides of the fence are starting to realize how much they can accomplish when they stop name calling and start working together. Personally, I’m pro gnome. If my school installed 100 kde desktops, that would still be a win for open source as they share much of the underlying infrastructure.
You’ve put the horse before the cart there. Gnome used to use Corba and Bonobo. KDE looked at that and came up with KParts and DCOP. They designed both to be “clean, and easy to use”.
Corba and Bonobo got nowhere as they were very, very hard to use, so the Gnome devs took a good look at DCOP, and created their own implementation, with a few tweaks here and there: this was D-BUS.
This – incidentally – is why KDE was able to switch to D-BUS so quickly: it’s actually very similar to DCOP, and the Qt bindings for D-BUS make it even more similar.
Indeed, KDE has inspired a lot of the freedesktop.org choices: for example the icon theme spec is very similar to the current KDE one. However this is not the only reason KDE developers are working quite hard with freedesktop.org (check out who’s working on the Portland project): I think it’s become pretty clear to them that KDE needs to be interoperable with Gnome, as most of the popular distros are defaulting to Gnome these days.
I think it’s become pretty clear to them that KDE needs to be interoperable with Gnome, as most of the popular distros are defaulting to Gnome these days.
That’s definitely not their motivation. I think they would like to have good general purpose technology that people outside KDE can actually use, contribute to and make better. DCOP was fantastic in the KDE world, but it was unfortunate that no one else used it or even knew it existed. It’s always struck me that Gnome like to use quick fixes that have a limited shelf life and end up not solving anything.
As for many distributions defaulting to Gnome, that’s just a fallacy. The vast majority of Linux desktop users, by any reasonable metric, still use KDE. The enterprise desktop stuff that Red Hat has wisely said doesn’t exist, and that Novell seem to have some fixation with, is miniscule when compared with Linux desktop’s current userbase.
You’ve put the horse before the cart there. Gnome used to use Corba and Bonobo. KDE looked at that and came up with KParts and DCOP.
So do you, you are really confusing the timeline here.
KDE used Corba in the 2.0 development, but early on saw it was not a good solution for the desktop. And they developed DCOP as a clean, light weight, fast and easy to use alternative for the desktop. This was long before Gnome started on it’s Corba/Bonobo road.
Why they refused to learn from KDEs experience, and choose a solution having more hype than fitness for solving the problem is still strange. Looking at the old mailinglist traffic it sounds mostly like a combination of NIH syndrome and a superiority complex of some kind.
Edited 2006-05-31 21:43
Why they refused to learn from KDEs experience, and choose a solution having more hype than fitness for solving the problem is still strange. Looking at the old mailinglist traffic it sounds mostly like a combination of NIH syndrome and a superiority complex of some kind.
The strange thing is that the general OSS community, where the GNOME people is included, tend to be the first to flame the KDE people for sufferint the dreaded NIH (Not Invented Here) syndrome. The Phonon debate as a prime example of that type of mudslinging, although the KDE people took the best solution they could take. Yet, the KDE people are the first to adopt changes to their project from others, where the other projects tend to take the NIH path themselves.
I hope that the OSS community starts to smart up about that whole NIH issue regarding KDE. They are doing a hell of a job not only bringing up the greatly antecipated KDE4 but also commiting themselves to the cause of open standards.
Edited 2006-05-31 22:49
Why they refused to learn from KDEs experience, and choose a solution having more hype than fitness for solving the problem is still strange.
One argument was that Corba was some sort of standard, but it was obvious to everyone in the real world that Corba had been shunned by just about everyone in terms of practical usage. You had to write a good two or three layers of code on top of it to get it to do anything remotely applicable to what you wanted to do.
On the Gnome side there seems to have been a complex about many things. There was a huge debate about ‘finding a response to Microsoft’s COM’, and it seems Corba and Bonobo was supposed to be that, and of course, more recently there has been an urge to ‘find a response to Microsoft’s .Net’.
Sorry in my post above I meant to say that, I think DBUS is easy to use and if it wasn’t, the KDE devs wouldn’t switch.
Not that DCOP was bad, but standarization on one technology for both Gnome and KDE will increase the possibilities for hassle free interoperability, and more time can be spent on improving things that matters to the users.
Not that DCOP was bad, but standarization on one technology for both Gnome and KDE will increase the possibilities for hassle free interoperability
Well, Gnome doesn’t use DBUS in the complete way that KDE does, and that KDE used DCOP, and it only solves part of the battle. You can’t have different applications working together unless they agree on what is being sent. DBUS, quite wisely I think, specifies very little in that way.
However, I do now hope KDE gets a lot less of this ‘Not Invented Here’ stuff thrown around. It’s most unfair.
One of the great advantages of a common IPC framework is the possibility of shared services.
By exposing desktop factility as services over D-BUS instead of through a library, it allows applications, especially those not developed for either framework, to access a facility independent which process is currently implementing it.
This means less additional processes to start if a an application is launched in the other desktop’s environment and it allows to eventually separate a service from the desktop frameworks and establish it as a project of its own.
Please excuse me if I’m wrong, but KDE seems to adapt to GNOME, using tech developed for GNOME. I don’t see anything wrong with DCOP. It worked well for years and it was simply enough. I know interoperability is necessary, but why GNOME didn’t adopt DCOP if C bindings where available.
DBUS is not really a GNOME technology.
It was carefully designed to be desktop agnostic and meet various peoples needs. It uses pure C at its core (no glib) and is security audited. Havoc Pennington wisely drives developement (taking care of any personal issues) with clear goal of making it de facto linux (free unix?) high level IPC.
KDE must use lot more technology from GNOME!
KDE is very messy, complex and cluttered.
C++ is no way to go, never was, never will.
KDE _MUST_ adopt gnome technology (is real technology after all, not just bunch of incompatible binary-messy libraries) or has to face to die!
Is true!
Everything tends to gravitate towards C. KDE does not adoprt GNOME tech. Rather, when a neutral C implementation of a technology is made both switch to it. The “Native KDE” methods will never be adopted by GNOME, and vice versa.
D-Bus is like a next generation DCOP. It makes some things more complex, e.g. Introspection through XML data, but it allows a greater range of possibilities, for example operating as a system bus for communication of user applications with system applications/daemons.
And since D-BUS is not a “tech developed for GNOME” but rather an independently developed new technology, GNOME and KDE are switching to it rather than one to the other’s communication system.
I just don’t hope gnome missed DBUS.
But seriously, FreeBSD has suffered a bit on the desktop because of a lack of HAL. (They’re now plugging that hole) If KDE4 comes to depend on DBUS, where will that leave the BSDs? Unsupported? Crippled?
I think KDE and GNOME should try to be UNIX desktop environments, not Linux ones. But then again, if they’re using better technologies, maybe it should by the BSDs who should be playing catchup?
[elvis@rubik ~]$ ps ax | grep dbus
658 ?? IWs 0:00.00 /usr/local/bin/dbus-daemon –system
[elvis@rubik ~]$ uname -a
FreeBSD rubik.dose.se 6.1-RC FreeBSD 6.1-RC #0: Sat Apr 8 21:33:08 UTC 2006 [email protected]:/usr/obj/usr/src/sys/GENERIC i386
DBus has been running fine on FreeBSD for quite some time.
Regards,
Aron
Dude, DBUS is on FreeBSD. http://www.freshports.org/devel/dbus/ Why do people believe FreeBSD doesn’t have DBUS?
It has been a while since I last looked at D-BUS. Looking at http://www.freedesktop.org/wiki/Software/dbus I found that D-BUS requires an XML parser. OOOHHH NOOOO, I thought, not another project that thinks it is a great idea having computers talk to computers with plain text messages.
Last time I looked at D-BUS I didn’t saw any thing about XML, so I took a look at the specification. To my relief I found that it does not use XML “on the wire”. Great!!!
So why does it need an XML parser? I saw something about converting D-BUS messages to XML. But why is it a requirement and not just optional?
Edited 2006-05-31 23:52
So why does it need an XML parser?
it’s used to create the introspection data (meta-data about the interface, the objects and the signals that you export). also, some bindings (like the GLib ones) create stub code from the XML definitions – much like corba uses IDL to create stubs for the objects.
the stuff that goes on the wire is indeed binary, and uses its own very well documented protocol, so that if you want to create a drop-in replacement of the deamon you can do it.
I just hope I don’t need glib and friends for kde now…
Its already using it.
Well, you’ll still need glib anyway, for gPhoto support.
Nothing wrong with glib as it expands libc further – quite frankly, what should be of greater concern is making sure that the amount of duplicated projects is reduced down to a point that the differences between gtk and qt as so transparent, one can easily mix code without needing to worry.
GLib has no dependencies (other than LibC, which every Linux program barring the kernel requires), and weighs in at 900KB.
It is one third the size of an MP3.
It is three times the size of a 5MP photo stored as a JPEG.
If you listen to MP3s when you work, or if you have a photo from your camera as a background image, you really can’t complain about GLib being “bloat”.
Speaking as someone who prefers OO languages, I think GLib is a perfectly fine library that takes a lot of the pain out of C programming. If I ever had to do anything in C, I’d use it in an instant, and I have absolutely no qualms about its usage in things like KDE.
Because DBUS was developed by Gnome but by freedesktop. As for the question about why not DCOP ? The answer is simple, DCOP is a user only bus, this means you cannot use it for communication with hardware layer (like HAL and co, for usb hotplay). DBUS is a modification of DCOP to allow such an use. And apparently it was impossible to make those modifications and be compatible with DCOP.
KDE does the best it can to stay a UNIX desktop environment. many KDE contributors run some BSD, and most things work on both BSD and Linux.