I’ve been promising a release of GtkUnique for a while now, but work and other stuff got in the way of the namespace change-slash-rewrite. Yesterday I finally got around finishing the porting of the Unix domain sockets backend (or “bacon”) so I cooked up a preliminary release with the D-Bus and Bacon backends working. You can find the tarball here or, if you’re feeling in hacking mood, you can check out the git repository from here:
git clone http://www.gnome.org/~ebassi/git/unique.git
the unique-0.9.1 is the tag for this release. I’ll work on finishing the port of the Xlibs backend and target a stable 1.0.0 release for GUADEC.
The API of Unique changed a bit since the last GtkUnique release, and I think it’ll change a bit more in order to be usable with the smallest impact possible. Now you can register custom commands and there’s convenience API for sending strings and URI lists; the command registration and construction API might change to something similar to the GtkDialog API – and I might switch to a more signal based approach (construct the message payload inside a signal handler) before 1.0. I also might add a –replace command line switch that gets slurped and does The Right Thing for you.
The biggest change is happening under the hood, though; with this release, the UniqueApp instance will request the specified name as soon as it is created, so you’ll be guaranteed to either be the first running instance or be able to send messages to the currently running instance at the same moment that the UniqueApp constructor returns. Hence, no more race conditions between the constructor and the “is running” request. Finally, the “window watching” functions have been removed – even though I might add a “watch window” function to handle the startup notification sequence for you (now that we have the API to do that in GTK+ 2.11).
This release also means that the code in SVN under the gtkunique module is to be considered deprecated. I’m going to ask the svnmaster to move it into the attic, as the delta is too big for a simple check-in. As soon as 1.0.0 is out I’ll also ask the release-team for “blessing” Unique as a dependency, so if you want your module to depend on it you’ll be able to safely do it. Again, sorry for taking this long to finish up this work.
Update@2007-07-09T15:16+0100: I’ve just rolled a 0.9.1 to fix some build issues and add licensing terms. Thanks to Christian Persch for the heads up.
It doesn’t bring window to front when you run another instance from terminal (and it warns about `startup_id != NULL’ so it probably wants startup id to be set).
U IZ UNIQUE
And X backend has the same bug as in the backon thing: uniqueness is per-host, not per-display.
@muntyan:
the terminal steals focus for every application it launches: it’s not a bug in Unique, is the intended behaviour of the terminal. the Xlibs backend is not included because it’s going to be rewritten; the bacon backend is per-host but I can add per-display too.
Intended behavior, right. So gedit and others break that, and people who want the application to pop in front want some wrong thing? Come on, what does “intended” mean? I don’t believe anyone has ever made the decision like “applications launched from terminal must not get focus”. Unfortunate consequence of how things work, yes. But not intended behaviour.
Terminal doesn’t steal anything, it simply unsets startup id in itself as it should do, and naturally startup id doesn’t get set in applications started from terminal. It’s application business to cope with it (well, it’s really toolkit business, but given gtk doesn’t provide anything for this, it naturally would be a task for UniqueApp).
Anyway, dbus backend actually is per-display, X isn’t (how is it not included if it is included?)
@muntyan:
mmh, right: I was under the impression that metacity still had the strict focus handling turned on by default – even though it might very well be on some distributions.
the xlibs backend that was available in gtkunique is not included in unique because it’s still not ported to the new internal API and it’s still suffering from a race condition; the dbus backend is per-display because it uses the session bus, while the bacon backend is per-hostname.
Um, I still didn’t get what’s included into what. I did
git clone http://www.gnome.org/~ebassi/git/unique.git
and it built X backend for me, whatever it means :)
It was per-host. When I built it with dbus, it was per-display (I do have desktops running on both displays). Which makes me wonder, does UniqueApp handle the case when dbus isn’t available? (I suppose dbus session is started with your desktop, so e.g. if you simply login using ssh and start something, you don’t have dbus session)
until d-bus works over ssh (or, better, ssh exports the d-bus session), no: there’s no way that a version of Unique compiled against D-Bus runs through a ssh-forwarded X session.
Perhaps dbus is not such a good idea then? Having X-win32 or mac X server without desktop is not something extreme, and some applications rely on working input channel for many things.
Applications like devhelp or gedit while having per-host bug (if you run an instance on another display, then you have to kill that to run gedit here on this display) are still usable as long as you don’t have that another instance. If they use dbus, then the single-instance logic won’t work over ssh or similar, which could even actually break things (Paolo Borelli once told me it’s important to have single process due to some settings stuff).
Or perhaps compile-time choosing backend is not good?
Will Unique handle startup-notification internally? It might be a good idea to do so if it is possible, so that apps don’t have to support this themselves. This would fix the focus-stealing bugs too, as Uniue-ified apps will play nice with Metacity by default.
Small question. Is the long term plan to integrate this in GTK+/GLib? If not, why not?
@l
yes, the plan is to handle the nuances of a startup notification for you; at most, you might end up writing gdk_notify_startup_complete().
@martin
long term plan: yes, as soon as gtk+ has a GtkApplication class that can be used as an ancestor for a UniqueApplication class.
@muntyan
that’s why Unique has multiple backends; gedit, for instance, can either depend on a specific backend or copy the code from unique and use it (it’s LGPL).
Ah, good! :) I was getting a bit worried there for a moment. But I should have known better. ;)
Keep the excellent stuff coming!
Problem is, gedit won’t depend on backon backend. I am patching devhelp deb regularly since developers do not care about running it on multiple displays; I can imagine how gedit (devhelp, whatever) folks make their application depend on bacon backend – dbus is sexier or otherwise superior, so naturally everyone wants dbus today.
So it’d be good if libunique hid backends from the user, and chose working backend in runtime. After all, why should application developers care about “bacon” or “dbus” if all they want is the “unique” functionality. In fact I was reqally surprised the package installs two separate libraries, I thought there was a libunique.so which is built using compile-time-chosen backend.
Sorry if it seems ranting, but it’s just not wanting another broken thing used everywhere (bacon simply ignores display and that’s it, if it did use display in its socket name, nobody would 1) notice, 2) object to it).