Re: GNOME 2.10 module proposal: libnotify and notification-daemon

[Havoc Pennington <hp redhat com>]

On Sun, 2004-11-28 at 21:13 -0500, Colin Walters wrote:
> So how does this map to D-BUS activation and services?  You mentioned
> you thought everything should be lifecycle-managed by D-BUS, which makes
> sense to me.  But is it just assumed that desktop extensions will
> connect to the session bus and acquire some service?  Should desktop
> extensions install D-BUS service files?  If so, what happens if it's not
> in the GConf list, but another application wants to activate it?

I would think the gconf list is just "stuff to activate at login time"

Of course dbus only helps for out of process, you can't use it for
dlopen modules.

I'd think we should add a single-instance API to GTK+ where the app
basically registers a callback:

void
new_instance_callback (GdkScreen      *default_screen_for_instance,
                       int             argc,
                       char          **argv)
{
   /* Create a GtkWindow for each document in argv or whatever */
}

The idea is that GTK+ would parse its args such as --display, determine
the default screen, and pass remaining args to this
new_instance_callback in the existing instance of the app.

Maybe not the right way to do it, it's complicated 
e.g. http://freedesktop.org/pipermail/dbus/2004-July/001323.html
talks about it a little. I believe the right solution involves declaring
that any command line option or env variable that doesn't make sense to
apply to the existing app will not be handled. In other words you can't
make the nature of an activatable item depend on how it was activated,
as in this example:
http://freedesktop.org/pipermail/dbus/2004-January/000667.html

Havoc