Re: LibUnique as blessed dependency

[Havoc Pennington <hp redhat com>]

Hi,

Is libunique really the right approach? To me, I think there are two 
approaches I would consider:

1) a cross-platform API in GTK using Xlib (via X selections) on Linux 
and whatever on Windows, so this is cross platform and no dependencies.
I guess the cross-platform API in GTK could also use D-Bus if it jumped 
through the right hoops to make it optional or something.

2) an addition to whatever D-Bus binding people are using that makes it 
simpler to do "single instance" with a dbus bus name
As I wrote in http://log.ometer.com/2006-11.html:

   For applications that want to be single instance and can just rely on
   D-Bus, there's no need to wait for a fancy "unique application"
   library - just try to own your app's D-Bus name on startup, and exit
   anytime you lose the name or fail to become its owner. Presto,
   single-instance. (This is what bus names were designed for, btw.)

D-Bus bus names are modeled on X selections, and both are designed as a 
way to have a single-instance service.

The thing I don't understand about libunique is the multiple backends 
aspect. Why does it have that? GNOME requires Xlib and X selections, and 
it requires D-Bus also. Being configurable between those two *could* 
make sense for GTK, but not for GNOME that I see. And having a third 
backend doesn't make sense to me for either GTK or GNOME.

It seems like too small a piece of functionality to have in a separate 
library, especially if there aren't multiple backends.

I think I had some other comments on the bug report too, e.g. about 
having stuff in gtk so that running the first time looks identical to 
the app vs. running the second time (basically have main() just set up a 
callback, which is then called for both the first and subsequent 
launches), but the above is the macro point.

A real advantage of saying D-Bus is the one true way, rather than having 
a configurable backend, is that you don't HAVE to use a C library. If 
you're using python and D-Bus is simple to use, then to run the app 
org.gnome.MyAppName you just do a thing like:
 proxy = dbus.whateverthemethodiscalled('org.gnome.MyAppName')
 proxy.NewDocument()

A second real advantage is that arbitrary new commands can be supported, 
not just NewDocument() or Launch() or whatever the main single-instance 
command is.

libgtkunique at least used to have a way to do multiple commands, but it 
was kind of a limited and ad hoc IPC system; why not just _use_ the IPC 
system we have?

We can also ship a small binary with dbus that does something like:

 - takes a command line arg which is the dbus bus name of the app
 - parse command line args such as --display
 - grab startup notification stuff from environment
 - stuff all of the above in a dictionary_of_stuff
 - call a Launch(dictionary_of_stuff) method on org.gnome.MyAppName

Call this dbus-app-starter or something. So you use it like:

 dbus-app-starter org.gnome.MyAppName --display :0.1 --other-arg

So the way you do a single-instance app is:
 - ship a .service file that runs your app (probably you put the
   app itself in libexecdir)
 - ship a .desktop file that has an exec line:
    dbus-app-starter org.gnome.MyAppName
 - optionally, install to /usr/bin a script that just runs
   dbus-app-starter, so people have a friendly name for your
   app to type in a terminal

If you want your app to support custom commands, you just support 
methods other than Launch() that do whatever you want.

The right standard method might not be Launch(), it might be 
OpenDocument() or NewDocument() or something like that, or maybe all of 
the above.

To supplement dbus-app-starter you'd also need functionality in GTK or 
other library to handle the incoming Launch() method call and set up 
startup notification etc. using the info in the dictionary.

Going a bit broader in scope, our D-Bus usage is all over the map and 
needs more structure; the bindings or some convenience API needs to 
support common operations such as:
 - taking action whenever a particular service appears
 - single-instance using a bus name
 - keeping track of "who is using my service" in order to send
   them callbacks or decide whether to exit

I've thought about writing a little library for this stuff (there is a 
hippo-dbus-helper.c cut-and-pasted to a couple online-desktop modules 
already). If we did this then it seems like unique app functionality 
could be in a combination of this library and GTK.

Anyway, I don't want to slow anyone down and if people want unique app 
functionality now I guess we should use the work that's been done, but I 
did want to say my piece rather than complain after it's too late.

Havoc