Re: using dbus in the platform
- From: "Brian J. Tarricone" <bjt23 cornell edu>
- To: gtk-devel-list <gtk-devel-list gnome org>
- Cc: dbus-list <dbus lists freedesktop org>
- Subject: Re: using dbus in the platform
- Date: Thu, 18 Oct 2007 10:31:18 -0700
Havoc Pennington wrote:
[a lot of intelligent stuff about using dbus in our stack]
As an Xfce developer, I'm usually one of the first to be wary and
skeptical when large new bits of functionality are added to glib and gtk
(we try to use lightweight libraries with as few dependencies as
possible), but at this point, I must say Havoc is right, and this is the
correct way to go.
We started using dbus in Xfce about a year ago, albeit in a limited
fashion, and mainly for desktop/file manager integration. For our next
major release (due sometime eventually whenever and stuff ^_~), we're
planning on using dbus a lot more -- in our configuration system, for
starters, and most modules (desktop, panel, etc.) will have some kind of
dbus remote control interface, which should help solve several problems
our users have -- picking a random image from a script and setting it as
the desktop wallpaper every hour, to name one example --
problems/desires that we don't necessarily want to solve directly in our
software, but we'd like to give users (and perhaps other developers) the
flexibility to do this on their own outside of Xfce.
Now, I know what's being proposed isn't "add dbus to gtk" -- the parts
of gtk that use dbus will neatly hide dbus. My point is that a
standard, flexible, lightweight, easy-to-use form of IPC is starting to
become (or maybe already is) essential to an integrated desktop
environment, not just to present a unified look, but to make
extendability and flexibility easy and within reach to your average
non-programmer power user. D-Bus was designed to be this IPC mechanism,
and IMHO it does a pretty damned good job of it, certainly better than
tossing around length-limited XClientMessages or re-inventing a custom
unix socket protocol for every single app.
The use cases described seem valid and worthwhile to me; currently our
method of ensuring single-instance is to grab an X selection on startup.
While that works, it's not portable, and is a departure from the
high-level nature of gtk. I consider it a failure in the stack whenever
I have to use xlib for anything that isn't truly x11-specific. I could
go on, but... you get the idea.
-brian
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]