[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: using dbus in the platform
From:       "Brian J. Tarricone" <bjt23 () cornell ! edu>
Date:       2007-10-18 17:31:18
Message-ID: 47179866.3030407 () cornell ! edu
[Download RAW message or body]

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
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]