Re: using dbus in the platform

Havoc Pennington wrote:

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.

API goals like "manage the screensaver" simply fall outside of GTK+'s job description. I don't think you understand the diversity of scenarios GTK+ is used in.

For example, NDesk, a "Linux" desktop environment based on GTK+, does not have screensavers. It has a login screen displayed alongside a panel of desktop accessories ("widgets"). I sincerely doubt that any generalised "screensaver" API added to GTK+ would represent this model accurately.

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.

Have you ever tried to pop up a platform notification on Windows (calling into Internet Explorer's private vtables does not count)? Have you managed to get a notification on OS X without first downloading Growl (which implements its own IPC system)? Or are you so determined to support your argument that you are making shit up about other platforms and hoping that nobody notices?

D-Bus is how KDE and GNOME are implementing this stuff. But it is by no means universal, even on Unix.

The Hiker project (, a mobile application framework based around GTK+, uses ALP IPC (

NDesk currently uses .NET remoting, a cross-platform IPC system. I have been investigating switching to D-Bus (NDesk.DBus is part of the effort) but the jury is still out on this.

Moreover, if NDesk switches to D-Bus, it will probably use D-Bus on *all platforms*. This is at odds with your plan to use D-Bus only on "Linux" (I'm not even sure what you mean by "Linux") but not on other platforms.

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.


gboolean gtk_help_show        (GdkScreen   *screen,
                               guint32      timestamp,
                               const char  *help_system_name,
                               GError     **error,
                               const char  *first_param_name,
                               const char  *first_param_value,
                               const char  *second_param_name,
gboolean gtk_help_show_valist (GdkScreen   *screen,
                               guint32      timestamp,
                               const char  *help_system_name,
                               GError     **error,
                               const char  *first_param_name,
                               const char  *first_param_value,
                               const char  *second_param_name,
                               va_list      var_args);
gboolean gtk_help_show_array  (GdkScreen   *screen,
                               guint32      timestamp,
                               const char  *help_system_name,
                               char       **param_names,
                               char       **param_values,
                               GError     **error);

Are you being serious? This is a perfect example of why it doesn't make sense to move this kind of API out of the desktop environment and into the toolkit.

I would frankly be embarrassed to propose an API like this on a public mailing list. Do you think it is somehow clever to dispense with type-safe parameters in favour of arrays of strings and varargs? Did you congratulate yourself when you abstracted the set of all possible help systems using an array of strings?

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).

When I'm writing GNOME applications, I will use the the GNOME settings and VFS libraries du jour, say GConf and GVFS. They are expertly designed to meet the requirements of GNOME applications.

You *cannot*, however, impose your favourite settings and VFS libraries on all GTK+ applications.

It may be news to you that some GTK+ applications outside of GNOME already use portable frameworks for settings storage and IPC that have been peer reviewed, published in academic journals, and make GConf and D-Bus look like the immature scrawls of a toddler.

If you want cross-desktop standardisation, publish your settings D-Bus API on Freedesktop and developers can implement in their platform (or use your libgsettings) by their own free will.

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.

NDesk takes a different approach to processes and unique instances than GNOME -- essentially, an application or component can at any time be either in-process or out-of-process.

As another example, some of the Hildon API appears to be designed to support embedded operating systems that may not even allow for process concurrency. Did you even consider that?

If you are claiming that you can develop an API in GTK+ that represents these and other forms of application modality, you are being incredibly arrogant.

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.

The objection here does not concern "tiny corner-case details".

The objection is to the inclusion of IPC and other non-toolkit features in GTK+, a UI toolkit that is ported to several UI frameworks spanning several platforms, and is the basis of perhaps a dozen application frameworks for desktop and mobile devices, each with its own "HIG", memory footprint, set of conventions and API requirements.

Can we now lay to rest this absurd idea of using D-Bus in GTK+?

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