Re: using dbus in the platform


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 coherent way.

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]