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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
