[arch-general] [OT] What is wrong with DBus anyway?

Jan de Groot jan at jgc.homeip.net
Fri Dec 4 07:24:01 EST 2009


On Fri, 2009-12-04 at 03:38 +0100, Arvid Picciani wrote:
> Ng Oon-Ee wrote:
> 
>  > What does upstream have to say about this dependency? Does not seem
>  > 'necessary' to me
> 
> http://blogs.igalia.com/itoral/2006/03/30/adding-dbus-support-to-gedit/
> 
> priceless finding.
> 
> let me sum up:
> "
> - There is feature X which works very well
> - He discovered it doesn't use dbus.
> - He starts work on a very complicated patch that makes it use dbus.

Let's sum up:

- there's a feature using a deprecated library (bacon uses the
bonobo-activation framework)
- he discovered the new way to do these things is by replacing it by
dbus
- he starts work on something that replaces bacon/bonobo and uses dbus

Really, you're just having a 100% anti-dbus attitude, but somehow you're
fine with Bonobo. Maybe you didn't know, but Bonobo is worse than dbus.
It's a complicated slow framework with a lot of design mistakes.

The problem with dbus here is that Bonobo was matured, dbus is quite
young. Dbus was lacking some features in the beginning, causing nasty
regressions. One example was the lack of possibility to pass environment
variables to a dbus-launched application. I don't know if this is
possible already, but I think they worked around the limitation by not
using environment variables for such stuff anymore.

Note that a lot of work has been duplicated in applications when they
were ported to single-instance applications using dbus. This has been
fixed by using the libunique library. At this moment anjuta, brasero,
devhelp, gnome-bluetooth, gnome-control-center, gnome-disk-utility,
gnome-power-manager, nautilus and totem use this library for their
single-instance functionality. Gedit uses its own complicated way and
should switch to this library also if possible.



More information about the arch-general mailing list