Weekly Edition
Return to the Press page
| |||||||||||||
|
| |||||||||||||
Connect KDE apps using D-BUS (IBM developerWorks)
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."
(Log in to post comments)
Connect KDE apps using D-BUS (IBM developerWorks) Posted Jul 30, 2004 22:51 UTC (Fri) by edmundd (guest, #14677) [Link] 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] glib is a set of C libraries to provide a large number of functions andstructures 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
JimD
Not necessarily a bad thing Posted Jul 31, 2004 6:29 UTC (Sat) by boudewijn (subscriber, #14185) [Link] On the other hand, glib should be used by no C++ program, since there arefar 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] 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:
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] "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] 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 (subscriber, #5220) [Link] 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 (subscriber, #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 (guest, #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 (guest, #774) [Link] The title now reads "Connect desktop apps using D-BUS". ;-)
D-BUS Posted Jul 31, 2004 14:29 UTC (Sat) by meffie (guest, #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 (subscriber, #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
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
Here are some possible answers:
1. CORBA is 'heavyweight'.
2. The C++ mappings suck.
3. It's insecure.
Don't get me wrong, I'm not a huge fan of CORBA, but it does get some things right. There needs
These are worth reading:
|
|
||||||||||||