D-BUS is an up-and-coming message bus and activation system that is set to achieve deep penetration in the Linux desktop. Learn why it was created, what it can be used for, and where it is going.
Connect KDE apps using D-BUS
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
When I first heard about DCOP, it dropped my jaw (no innovation microsoft, bleh). Now Gnome will talk to KDE and vice versa. Being able to script GUIs like CLIs just rox!!
Yayy open source, go go….
//One happy linux user
Scripting applications was one of the nice feature of BeOS … years ago …. nice to see Linux finaly getting something similar … ;->
@Jean-Louis
You say that as if no Linux GUI applications at all could be scripted before this, which would be incrorect. There were scripting GUI Applications long before BeOS. If you want to get technical Apple had it before Be. So even if I followed your line of thought, it was nice to se BeOS catch up with MacOS, and *nix desktops catch up with MacOS later. Ahem.
…and on Amiga before BeOS. AREXX, remember?
It’s possible of course that this is the first in a series, and subsequent articles will actually involve KDE programming — but this article only mentions KDE and all the code examples are GObject-based.
That’s OK. This is interesting stuff, and I like the design. I don’t know where KDE stands here — it would make sense for them to swallow their pride and run with it (maybe providing a DCOP bridge), but there’s always contention, isn’t there? The last I had read, more than a year ago, some KDE folks were all for D-BUS and others were dead-set against it with the usual “GNOME code will pollute us”, even though D-BUS doesn’t depend on GNOME, it just happens to have been well-integrated on the GNOME side, and written by GNOME people.
As much as I feel KDE is the technically superior system, a linux desktop with D-BUS and with a fully D-BUS aware GNOME desktop will be, from a user standpoint, the superior system. And it’s the users who count.
The title of the article is a bit misleading, there’s really nothing KDE related in it at all. The examples covered are in C and Python. I’m guessing it’s more of call out to the KDE developers that it’s time they too should start looking at D-BUS, since there’s been a somewhat false perception of D-BUS as a GNOME tech. Anyway, the code makes it all seem really easy, which is good.
Once the Linux kernel events layer by Robert Love lands in a mainline kernel I’m betting we’ll start to see some interesting D-BUS uses by the two desktops. That’s the piece that bridges kernel events and user space applications using D-BUS.
D-BUS is an up-and-coming message bus and activation system that is set to achieve deep penetration in the Linux desktop.
Is it just for Linux, or could that description be changed to say “open source desktop” or “Unix-based desktop”? I thought Freedesktop.org was based on X, and available for any Unix-based OS. Anyway, it looks like promising stuff.
KDE developers don’t like C. And can’t stand the fact that D-BUS is strongly intertwined with Glib, a library developed by the GNOME folks. This one is political.
Shawn, Mikal, you guys are right, GUI scripting have been around for a whiles … it’s just that the first comment sounded a bit too much : “Woa look the cool stuff we just invented! There is innovation in Linux/OSS …”
dbus is not intertwined with glib at all, there are glib based bindings to use it yes, but you can use the underlying C interface without any problems, which can easily be wrapped up into a C++ interface just like it is for a GObject based system.
The thing about udev support sounds really useful. I like DCOP, but what’s kept it from me is that it’s tied too much to the KDE/QT architecture. I don’t mind D-BUS being C (one can write wrappers), but I don’t know how far the GLib integration goes (especially how much trouble it is to use D-BUS in, say, a Qt application).
From the article
DCOP is a solution for KDE, but it is tied to Qt, and so is not used in other desktop environments.
Dcop is not tied to Qt, DCOP is based on X’s own IPC mechinism.
@Anonymous Re: Errorz
Dcop is not tied to Qt, DCOP is based on X’s own IPC mechanism.
While that may be, the problem is that the majority of applications that use it send serialized Qt objects.
Read this page for other reasons why DCOP is not necessarily a good answer:
http://www.arts-project.org/doc/mcop-doc/why-not-dcop.html
Mystilleef: “KDE developers don’t like C. And can’t stand the fact that D-BUS is strongly intertwined with Glib, a library developed by the GNOME folks. This one is political.”
Uh, no. KDE is actively thinking about migrating to DBUS, they have no “political reasons” for not to do so. They are hesitant since it would be a big undertaking. And DCOP already gives them what DBUS would give. AFAIK, the primary plan (for now at least) is to write a DBUS/DCOP wrapper.
Reasons are not political. They are 95% practical and technical.
having a standardized IPC between the two big desktops would be wonderful.
I’ve always wondered why wasn’t DCOP just extended instead of creating an entirely new IPC? D-BUS seems to be “inspired by” or somewhat based on DCOP (probably not code, but the idea).
Excuse my ignorance, for some rather odd reasons, I thought D-BUS was dependent on Glib. I must have misread something.
Re: standsolid
Probably because DCOP at this point is fairly heavily tied to KDE libs, etc. While DBUS is desktop-agnostic and lighter weight, it also has functionality similar to what dcopc provided, but unlike dcopc actually works.
Mike wrote:
> …and on Amiga before BeOS. AREXX, remember?
and on different Unices (and even on OS/2): Rexx, remember?
<<but unlike dcopc actually works.>>
After several years, GNOME has decided to copy (yet another) great KDE idea. Nothing wrong with that.
DCOP works great here, and it’s very easy to develop with. What (imaginary?) issues keep it from working for you?
I don’t know where KDE stands here — it would make sense for them to swallow their pride and run with it (maybe providing a DCOP bridge), but there’s always contention, isn’t there?
I think it would make sense for some people to swallow their pride and admit that CORBA sucks for pretty much all of the desktop stuff you’re going to do.
As much as I feel KDE is the technically superior system, a linux desktop with D-BUS and with a fully D-BUS aware GNOME desktop will be, from a user standpoint, the superior system. And it’s the users who count.
Given that KDE is fully DCOP aware absolutely everywhere, people have a good right to ask what the point of D-BUS is. And when will Gnome ever be fully D-BUS, or even Bonobo, aware?
@[email protected]
DCOP works great here, and it’s very easy to develop with. What (imaginary?) issues keep it from working for you?
You didn’t read what I wrote very carefully. Note I said dcopc NOT dcop, dcopc is the C interface to dcop which has never been well maintained. And gnome is not “copying” DCOP. IPC mechanisms have been around for years long before DCOP ever was, and DCOP was around before KDE was if I’m not mistaken. Do more research in your attributions.
Here are the relevant parts of the article:
1. “DCOP is a solution for KDE, but it is tied to Qt, and so is not used in other desktop environments.”
2. “Similarly, Bonobo is a solution for GNOME, but it is quite heavy, being based on CORBA. It is also tied to GObject, so it is not used outside of GNOME.”
3. “D-BUS aims to replace DCOP and Bonobo for simple IPC and to integrate these two desktop environments.”
4. “The library has been designed to be wrapped by other systems: it is expected that GNOME will create wrappers around D-BUS using GObject (indeed these partially exist, integrating D-BUS into their event loop), and that KDE will create similar wrappers using Qt. There is already a Python wrapper that has a much simpler interface, due to Python’s object-orientation and flexible typing.”
5. “Finally, D-BUS is being developed under the umbrella of freedesktop.org, where interested members from GNOME, KDE, and elsewhere participate in the design and implementation.”
RTFA before trying to start a KDE/GNOME flame war where one does not exist.
I meant to put “re: Shamyl Zakariya and Mystilleef”. But as you had already retracted your previous comment, my apologies.
Given that KDE is fully DCOP aware absolutely everywhere, people have a good right to ask what the point of D-BUS is. And when will Gnome ever be fully D-BUS, or even Bonobo, aware?
————-
very simple. Bonobo was found to be too heavy for complete integration throughout gnome while kde had much better success with dcop. dbus was created modelled on dcop but in a platform neutral manner and semantics are intended to be close to dcop so migration if required would be easier. directly using dcop wouldnt be possible due to the implementation being tied to qt,c++ and event loops
moreover dbus will work over the kernel events layer recently submitted to lkml by robert love so it will be a ipc mechanism both for system as well as user level interactions. it can also work as a deamon over a queue so its simple as well as flexible.
<<<You didn’t read what I wrote very carefully. Note I said dcopc>>>
My mistake, I thought it was a typo.
<<<And gnome is not “copying” DCOP>>>
LOL. I think one of Havoc’s early DBUS papers even credited DCOP as inspiration (no I don’t have a link). But my main point is that I remember Miguel and friends flaming KDE endlessly for picking DCOP over their superior CORBA choice. DBUS is pretty much a clone of DCOP replacing most (all?) CORBA uses hence the “copying” comment.
There has been something of a shift in freedesktop.org’s focus — away from making standards and towards providing a common platform. The fundemental problem with that is that, to the extent that any of these technologies are dependent on external code, they will have to be C/glib code — the GNOME folks would never accept a C++/Qt dependency. Both licensing and technology work towards this problem — glib is LGPL, Qt is GPL; C++ can call C code, but C code can’t (directly) call C++ code.
This situation poses problems for KDE that have nothing to do with pride — GNOME get’s to have a unified C/glib codebase, while KDE developers have to deal with bridges and wrappers and other crap to get the C/glib and C++/Qt worlds to be happy with each other.
> away from making standards and towards providing a common platform.
They still develop standards:
http://freedesktop.org/Software/dbus/doc/dbus-specification.html
But nowadays the standards have reference implementations.
> C++ can call C code, but C code can’t (directly) call C++ code.
s/C++/GPL/ s/C/LGPL/
If you meant this literally, it were just plain wrong. Since all C is valid C++ (keywords aside), you’d just have to compile your C code with g++ and voila, you can call C++ code (directly).
I almost didn’t read the article because I don’t do any KDE programming. But I figured to myself, “Ah, what the heck. There may be a few code snippets that I might snipe.” Lo and behold, it wasn’t KDE-centric after all! It’s a good intro to D-BUS and my system (which has glib2 but no Qt) could accommodate the example programs.
Great article!
If you want to try a D-BUS desktop now, you could try ROX. ROX-Session starts a D-BUS session bus on login. It uses it itself for configuration and other IPC, but once the bus is running other applications within the desktop can connect to the bus and use it for whatever they please.
http://rox.sourceforge.net
(a separate D-BUS bus is also used by zero-install, which you can use to install ROX easily)
If you meant this literally, it were just plain wrong. Since all C is valid C++ (keywords aside), you’d just have to compile your C code with g++ and voila, you can call C++ code (directly).
Of course I’m right. If you clean up all the keyword issues, and the deprecated behavior, and the type-safety issues, and compile your C code with a C++ compiler, you don’t have C code anymore, you have C++ code! Plus, the minute you use any part of a C++ library (eg: KWidget* kw = new KWidget), you’ve officially switched your project to using C++, and can’t go back to C again. I doubt the GNOME folks are going to be willing to switch to C++ at this stage in the game.
Interesting, I just installed DBUS the other day on my slackware laptop. Didn’t really understand what it did or if I needed it at all, but it sounded like a really good idea. Now if I only knew what applications on my laptop that would use it, and the command line to start it up I would be golden.
> Of course I’m right.
Yes, it looks as if you’re right… I thought g++ would compile C-style functions like gcc, but nm has proven me to be wrong.
From freedesktop.org site
D-BUS supplies both a system daemon (for events such as “new hardware device added” or “printer queue changed”) and a per-user-login-session daemon (for general IPC needs among user applications). Also, the message bus is built on top of a general one-to-one message passing framework, which can be used by any two apps to communicate directly (without going through the message bus daemon).
D-BUS has no required dependencies, but includes GLib, Qt, Python and .NET APIs to the D-BUS system, if you want to build those. The list of projects using D-BUS is growing and they provide a wealth of examples of using the various APIs to learn from.
D-BUS provides system (kernel) and session (IPC) daemon.
Difference between classic IPC and D-BUS is that while IPC is UNIX socket based. While D-BUS scales to network just fine as local. Second feature is SELinux integration and support.
DCOP is in C++ and as such it is hard to implement in non-objective language (but not even near to be impossible, just harder).
What I wonder is why author picked D-Bus-glib for KDE application when D-BUS-Qt bindings already exist a little googling and here it is http://www.kdedevelopers.org/node/view/246
Anybody have any performance benchmarks or stats?
How does this stack up against traditional system IPC (SysV messages, Named Pipes etc.) or desktop IPC (dcop, bonobo etc)?
How does this stack up against traditional system IPC (SysV messages, Named Pipes etc.) or desktop IPC (dcop, bonobo etc)?
——————
its not really comparable to named pipes. its faster than bonobo and simple and comparable to dcop. since dcop is tied to kde invidual stats cannot be very useful afaik. dcop wasnt slow by any means. dbus is already integrated well with fc2 and gets better in fc3 btw
> I’ve always wondered why wasn’t DCOP just extended instead of creating an entirely new IPC?
DCOP is based on X11 related transport and authentification systems.
D-BUS is more low level and can work without X11 running, thus bein useful for daemons, etc. as well.
As DCOP could be run over D-BUS, it is some kind of extension looking from the DCOP side.
> while KDE developers have to deal with bridges and wrappers and other crap
I think non of the freedesktop.org shared technologies depend on C or GLib.
Their current default implementation might, but for example for D-BUS the specification has the binary protocol, which can be implemeted in many forms.
And it has been made clear in relevant discussions on the freedesktop mailinglists that default implementations in C++ and even Qt are also welcome.
“D-BUS has no required dependencies, but includes GLib, Qt, Python and .NET APIs to the D-BUS system, if you want to build those.”
Why is it so difficult to understand ?
DBUS is *not* glib-based.
Of course I’m right. If you clean up all the keyword issues, and the deprecated behavior, and the type-safety issues, and compile your C code with a C++ compiler, you don’t have C code anymore, you have C++ code! Plus, the minute you use any part of a C++ library (eg: KWidget* kw = new KWidget), you’ve officially switched your project to using C++, and can’t go back to C again. I doubt the GNOME folks are going to be willing to switch to C++ at this stage in the game.
Perhaps the GNOME folks should switch to C++ 😉
C++, with it’s built in OOP, is the perfect tool for GUI libraries. The GTK+/GNOME developers stuck with pure C, but approximated OOP with GObject, totally reinventing the wheel, when they could have taken advantage of C++’s OOP power and elegance.
I love GNOME, and the design decisions the developers made to keep a clean, easy interface. I also love KDE, with it’s configurabilty, rich features, plethora of apps, power, eye candy, and finally, efficiency.
With C++, it is natural to use GUI libraries because the built in OOP handles polymorphism and inheritance very efficiently and elegantly. It is trivial to design new widgets extended/inherited from other widgets. C++ OOP is also a natural for organizing the library into a very logical, easy to use hierarchy.
I’ve also programmed small apps (for fun and learning) on both GNOME/GTK+ and KDE/QT. While I like both frameworks (both are superior to the Win32 API), I found QT to be much easier and productive to work with. Everything is built into the language and the library, with a simple, elegant API. With GTK+, OOP is utilized, but outside the native language (C), making the API more complex, and more prone to erros and inconsistency.
I’ve also noticed that KDE apps are faster than GNOME apps. Plus, KDE uses much less memory than GNOME (usually by as much as 50 megs).
Thus, C++ is probably the better language on which to build a GUI library.
And this post is not a C vs C++ flame – I like both. C is great for kernel, driver, and embedded work, while C++ is great for large scale apps, GUI apps, and general systems programming.
Also, this post is not a GNOME vs KDE flame I love both and regularily use both. But I do tend to use KDE more due to it’s lower memory usage, greater speed, and much greater features.
I’d like to note that no production, shipping desktop other than KDE uses a C++ based GUI library. Win32 is C based, Carbon is C based, Cocoa is Objective-C/Java, GTK+ is C, Motif is C. As far as I know only Qt is C++. The rest all use bindings.
C++ has a number of theoretical technical advantages – if you only use C++. It also has a number of practical disadvantages, for instance, the lack of a stable ABI.
Now, DBUS is cool. It takes a good idea (DCOP), does it better, and does it in a way that should be acceptable to everyone. I’ve used the DBUS API, it is really quite straightforward and pleasant even at the very low level, has decent integration security, is reasonably well specced out and documented, and has a C API suitable for using from other C apps or libraries, and it can be easily dlopened (this is a big deal, it’s really hard to dlopen C++ libs in a way that keeps their C++ness).
I say don’t argue just for the sake of it – everybody wins here. KDE had a great idea and are seeing it adopted outside of KDE, albiet in a different form. GNOME and other desktops get to use it instead of whatever they were using before, and 3rd party apps for the first time have access to a decent IPC system. Finally, DBUS has things like SELinux integration and is out-of-memory safe, good technical qualities for a desktop IPC switch.
I’d like to note that no production, shipping desktop other than KDE uses a C++ based GUI library.
That’s completely untrue. BeOS used a C++ based GUI library. MFC, which was long a mainstay of Windows programming, used C++. Also note that MFC wasn’t just a wrapper over Win32 — it implemented a great deal of it’s own functionality.
for instance, the lack of a stable ABI.
On Linux, C++ has a standard ABI too — the Itanium vendor-neutral C++ ABI. Aside from it’s age, it’s no different than the SysV standard C ABI Linux uses.
it’s really hard to dlopen C++ libs in a way that keeps their C++ness).
And this means, what?
I know Zack Rusin, a KDE developer was writing them, but as far as I know, they haven’t been released yet.
dbus seems cool and all, but I’d really like to see glib-less examples in C++.. hopefully using Qt. I have nothing against glib, but I:
1. don’t like C
2. don’t know glib
3. i’d prefer not to use #1 and #2 when I have something that works (DCOP)
The wonderful thing about DCOP is that it is extremely powerful and yet you can learn everything about it (except for maybe dcop stubs and refs) that it can do in less than an hour.
i agree with you on many points, mostly as a junior developer C is a huge stumbling block for me. When you learn the OO way first, its hard to go back 😉
I would go further then C++ though as acceptable GUI API languages go. longhorn is going to be using .net. osx uses objective C. both are memory managed languages, and this really seems the way of the future. C++ is better then C when it comes to gui work. but C# is better then C++ for pretty much the same reasons.
C++ is better then C when it comes to gui work. but C# is better then C++ for pretty much the same reasons.
Other than the fact that mangaged code (like C#) gives a huge memory imprint, as well as sucks up a ton of extra CPU cycles.
Virtual machines are great and certainly have their place. But due to the big memory and CPU usage of the VM, I’d rather avoid it for a GUI library/API, upon which to build fast, dynamic, large applications.
When did D-BUS become a GUI?
I am sure project utopia uses dbus for setting up discovered hardware and the like. it seems dbus is very well suited to a large number of tasks.
I am sure KDE could implement dbus in c++ if they felt so inclined. Its just that there is a reference implementation that seems to work well.
I am sure a bridge from dcop to dbus could be useful too to ease migration.