Connect KDE apps using D-BUS (IBM developerWorks) [LWN.net]

IBM developerWorks connects applications with D-BUS. "The typical desktop has multiple applications running, and they often need to talk to each other. DCOP is a solution for KDE, but it is tied to Qt, and so is not used in other desktop environments. 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. 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."

to post comments

Connect KDE apps using D-BUS (IBM developerWorks)

Posted Jul 30, 2004 22:51 UTC (Fri) by edmundd (guest, #14677) [Link] (12 responses)

Despite the title, the article is more Glib-centered. The author told me that the IBM editor slipped the KDE in there :)

Not necessarily a bad thing

Posted Jul 30, 2004 23:36 UTC (Fri) by AnswerGuy (guest, #1256) [Link] (10 responses)

glib is a set of C libraries to provide a large number of functions and
structures that are generally useful. They are somewhat object oriented, but they are not present as C++ classes and don't require that you use OO methods.

glib has nothing to do with the GUIs or toolkits. In GNOME those are built
over glib. So it's quite reasonable to build something like D-Bus over glib and it doesn't imply that D-Bus is more GNOME centric. glib should be used almost as much as glibc, by any C program that needs to build and manipulate common data structions like linked and doubly-linked lists, and also by applications that need to be more portable than the "standard" C libraries are currently implemented.

JimD

Not necessarily a bad thing

Posted Jul 31, 2004 6:29 UTC (Sat) by halla (subscriber, #14185) [Link]

On the other hand, glib should be used by no C++ program, since there are
far better solutions of C++ to manipulate common datastructures..

Not necessarily a bad thing

Posted Jul 31, 2004 12:49 UTC (Sat) by rjw (guest, #10415) [Link] (7 responses)

Except that D-BUS is *not* based on glib.

Because of the boneheaded decision to shove an object system into glib, rather than a separate library (it was understandable to take it out of gtk+), a lot of people (with their own object system) don't like it, and have decided that glib as a whole is a gnome conspiracy to ruin the purity of C++. Another strike against glib is the insistence on having typedefs for even the most basic types eg: (void*)-> gpointer . This makes it a horrific pain to lift glib-using code into a non glib context. Surely they can depend on standard C types by now?

All this makes it impractical to have glib as a dependency ( especially for system level stuff). Dbus contains copies of all the glib bits it uses.

However, it does have both GObject/glib and qt integration - allowing you to bridge it to either object system.

So:
* data structures in C : fine
* object system in in C : pretty distasteful to C++ purists

Even funnier than this is that the main opponents to GObject, KDE, don't use their languages supplied string and container classes : they have their own stuff from qt. Luckily the containers are now stl compliant..

I'm just waiting till someone creates an implementation of libc that implements everything using the stl underneath... that'll be the flamewar to end them all.

Not necessarily a bad thing

Posted Jul 31, 2004 14:31 UTC (Sat) by sandy_pond (guest, #9734) [Link] (3 responses)

"glib as a whole is a gnome conspiracy to ruin the purity of C++"

"object system in in C : pretty distasteful to C++ purists"

I wish these C++ purists would understand that C++ is a superset of C. C++ objects are implemented in C.

"I'm just waiting till someone creates an implementation of libc that implements everything using the stl underneath... that'll be the flamewar to end them all."

Why don't these C++ purists go off and write there own Linux++ and leave those who just want to make thing work together alone. While there at it they can write a "pure" C++ compiler.

Not necessarily a bad thing

Posted Jul 31, 2004 20:35 UTC (Sat) by nix (subscriber, #2304) [Link] (1 responses)

I wish these C++ purists would understand that C++ is a superset of C.

But it is not. It is a near superset, getting rapidly less so with the release of C99.

That does not mean that good C style and good C++ style are identical: far from it.

C++ objects are implemented in C.

I can't work out just what on earth this is meant to mean. The only case I can think of of a C++ object being implemented in C code is GNU libio, and that is specific to a single C++ ABI and only does such horrible hackery in order to ease the implementation of ios_base::sync_with_stdio().

Not a superset

Posted Aug 1, 2004 2:17 UTC (Sun) by pkturner (subscriber, #2809) [Link]

[C++] is a near superset, getting rapidly less so with the release of C99.

On the contrary, the discrepancies that arise from this 5-year-old (rapidly??) standard are in retreat. Quoting Herb Sutter from the C/C++ User's Journal,

At the Fall 2003 meeting, C and C++ already decided to adopt large parts of each other's work... at this Spring 2004 meeting, the C++ committee decided to adopt the C99 library extensions

Not necessarily a bad thing

Posted Aug 2, 2004 7:36 UTC (Mon) by anselm (subscriber, #2796) [Link]

> C++ objects are implemented in C.

That used to be the case back when Bjarne Stroustrup was still in
charge and the canonical C++ compiler was AT&T's »cfront«, which
compiled C++ to C.

For the last fifteen years or so at least, most C++ compilers have been
emitting assembly code directly, just the way C compilers do. G++,
for example, started out as an alternative front-end to the GCC
code-generating back-end, not as a C++-to-C compiler.

Anselm

Not necessarily a bad thing

Posted Jul 31, 2004 16:58 UTC (Sat) by hp (guest, #5220) [Link] (1 responses)

GObject *is* in a separate library. It's called "/usr/lib/libgobject-2.0.so" on my system.

Not necessarily a bad thing

Posted Aug 1, 2004 16:04 UTC (Sun) by rjw (guest, #10415) [Link]

This isn't enough for the worriers: it needs to be distributed separately.

Not necessarily a bad thing

Posted Aug 1, 2004 13:22 UTC (Sun) by marduk (guest, #3831) [Link]

I mostly agreed with this statement until I heard the words "conspiracy" and "purity of C++". Then I had to laugh.

Not necessarily a bad thing

Posted Aug 1, 2004 20:13 UTC (Sun) by dcoutts (subscriber, #5387) [Link]

Glib is not just common data structures, the other part of Glib (not the semi-separate GObject library) is an event loop system.

Not all C programs want to use this event loop. Eg some network daemons might want their own (glibs main loop is good even for network programming but was originally designed with an X connection in mind). Qt has its own main loop system, python & other language run-time systems also have their own.

Connect KDE apps using D-BUS (IBM developerWorks)

Posted Aug 2, 2004 8:19 UTC (Mon) by evgeny (subscriber, #774) [Link]

The title now reads "Connect desktop apps using D-BUS". ;-)

D-BUS

Posted Jul 31, 2004 14:29 UTC (Sat) by meffie (subscriber, #3120) [Link]

How long has D-BUS been around? Was it started by Havoc Pennington?

CORBA2 - reinventing the wheel?

Posted Aug 2, 2004 14:04 UTC (Mon) by alextingle (guest, #20593) [Link]

Sounds like somebody's reinventing the wheel. Why not just use CORBA?

> "The protocol is low-latency and low-overhead, designed to be small
> and efficient to minimize round-trips. In addition, the protocol is
> binary, not textual, which removes the costly serialization process.
> The use cases are biased towards processing on the local machine,
> so all messages are sent in the native byte ordering. The byte ordering
> is stated in each message, so if a [...] message does travel over a
> network to a remote host, it can still be parsed correctly."

Every word of this description applies to CORBA and its native protocol, GIOP.

What is the point of a completely new protocol, when there is a well-established one ready to
use? I really think this question needs answering, can anyone give me a link?

Here are some possible answers:

1. CORBA is 'heavyweight'.
Really? The underlying protocol is pretty lean. There is certainly a great deal of functionality
layered on top of that, but if you want a light solution, why not just implement the subset you
need?

2. The C++ mappings suck.
So make a new mapping, if you don't like it. Why throw the baby out with the bathwater?

3. It's insecure.
There is a whole secure infrastructure in CORBA, just waiting to be used. Why not build on that
rather than inventing something new?

Don't get me wrong, I'm not a huge fan of CORBA, but it does get some things right. There needs
to be real, serious justification for abandoning it all in favour of something completely new.
Where is that justification? What is the guarantee that the same mistakes will just be made all
over again?

These are worth reading:
http://mail.gnome.org/archives/orbit-list/2003-March/ms[...]
http://www.fresco.org/docs/refresco/