using dbus in the platform
hp at redhat.com
Thu Oct 18 09:27:59 PDT 2007
Simon McVittie wrote:
> I'm not convinced Gtk+ is the place to be experimenting with D-Bus
> integration. Can't we do the experimentation in a libgdesktopbus or
> libgnomebus or something, with convenience API for single-instance,
> notifications, etc., that hides libdbus, and if it turns out that in fact
> everyone wants it, push it into Gtk+ later?
The purpose of this is not libdesktopbus or libgnomebus; it's to flesh
out and complete the GTK+ application framework. We want to design the
platform with high-level API goals like "display help" or "manage the
screensaver" or "set preferences" and we use an implementation detail
like dbus as required.
The point about using dbus is that right now that is how we're
implementing this stuff on Linux. Windows has its own way, and GTK
should use that way on Windows, rather than dbus.
If you look at the example "GtkDesktop" code I posted during GNOME
summit, there is no hard dbus dependency there (well, no soft one
either, I didn't get to coding that bit); if someone came up with a
better way to implement the functionality, libdbus could be dropped.
GTK does not need to export an IPC API; that remains a separate library.
GTK does, however, need to *use* an IPC API, both directly and
indirectly because GTK should use GSettings and gvfs (for example).
In other words, the problem to solve is an incomplete app framework,
that leads to keeping large swaths of deprecated gunk via libgnome, and
a variety of one-off libraries that should be in gtk. dbus is only a
tool to solve this.
The app framework questions have already been pretty heavily prototyped
- via libgnome, gnome-vfs, libgunique, and so forth. So what's needed at
this point is to take those lessons and roll them into the platform in a
If we continued to do another prototype, following on to the previous
ones, I'm not sure what hypothesis the experiment would be testing. If
there are concrete lessons we still think we need to learn, then that
might be OK, but experimentation with no clear questions in mind won't
move us forward.
Please, let's stop obsessing about essentially tiny corner-case details
of the low-level dbus API and protocol parsing, all of which are fixable
with simple patches, when we have much, much larger problems - such as
1) no reasonable high-level IPC API for C whatsoever and 2) major gaps
in the app framework such as no GSettings, no way to show help, no way
to do single instance.
More information about the dbus