Re: using dbus in the platform

[Alp Toker <alp atoker com>]

Havoc Pennington wrote:
> Hi,
>
> 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 (http://www.hikerproject.org/), a mobile application 
framework based around GTK+, uses ALP IPC 
(http://www.hikerproject.org/doc/html/group___a_l_p___i_p_c.html).

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.

This?

http://mail.gnome.org/archives/gtk-devel-list/2007-October/msg00025.html

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+?