It's the last day of the OpenSync meeting in Amsterdam. Our fantastic organizing and press squad, Fab and Frank, have already spread the word. It has been a productive weekend. Lots of code got written. Armin and Tobias were busy with implementing out-of-process plugins for OpenSync which finally allows to seamlessly sync KDE and which also is needed for applications like the ones from the Mozilla family. I did some polishing on the GUI frontend side and implemented a first version of a D-BUS frontend for OpenSync.
Working with D-BUS was fun. At the beginning it took me a while to find working Qt3 bindings and to understand how D-BUS works, e.g. why you need miles-long command lines to make simple calls. There really are missing some of the conveniences we take for granted because we have tools like dcop or kdcop. But after getting over this initial adversities, I was able to quickly write a first version of a D-BUS service which talks to OpenSync and allows to control the syncing engine externally by using simple D-BUS calls. Again, there are still missing some of the advanced tools that we have for dcop, e.g. the dcopidl compiler, but it's pretty straightforward to work with D-BUS and the Qt3 bindings, so in the end I was quite satisfied. I'm looking forward to having better D-BUS integration and support in KDE.
Now I will get some sandwiches before Fab is getting me to the airport. Many thanks for organizing this meeting. It was a fun ride.
Everytime I read about D-Bus
Everytime I read about D-Bus its something like "its not as good as dcop, but...". Then, as a naive user, I ask myself: Why doesnt KDE stick to dcop then?
Re: Everytime I read about D-Bus
I think it is for compatibility reasons?
I'd guess DCOP uses Qt, while D-BUS doesn't depend on a toolkit.
I've heard it would use GLib, though.
GLib is more widely spread than Qt, and uses a different license.
The GNOME-guys use D-BUS, too (does it come from them?).
I can't think of GNOMEs using DCOP ;-)
So to be compatible to those guys KDE has to use D-BUS.
Another reason could be that DCOP works independently from any desktop environment, it is a system deamon afaik, so every DE that provides bindings can get access to it.
Yeah, DBUS is supposed to be
Yeah, DBUS is supposed to be a DE-independent DCOP. That means it can also run without a DE (and witout X of course). And because it is so low level it can be started early on in the boot process making it available for kinds of other low level services.
And although Redhat does seem to be the driving force behind DBUS and Redhat is known for it's Gnome support DBUS is completely Glib-less. The only thing is that the bindings that have received the most attention are the ones for Glib, but it's just up to KDE devs to make sure the Qt bindings are up-to-date as well.
And no, I doubt Gnome will ever use DCOP because it seems pretty bound to KDE although I might be wrong.
So in the end I think the KDE devs are looking to DBUS because they know it will become the standard if only because it is supposed to be the most "neutral" implementation (so no Gnome vs KDE battles necessary).