GtkUnique 0.1.0 has been released:
For the Google Summer of Code, Vytas Liuolia[1] wrote the (very much needed) guniqueapp library[2]; just a small recap: libguniqueapp allows the creation of single instance applications[3], that is applications that gets instanced once and each subsequent instance just quits - or send a command to the currently running instance.
Libguniqueapp has two available backends: D-Bus, as default, and bacon (a Un*x socket living in /tmp and used to send and receive commands). After reading about guniqueapp on desktop-devel-list, I began hacking on it in order to add a new backend, using X itself as an IPC mechanism.
Single instance applications are used on the desktop (Gedit, Mozilla, Epiphany, Evince - the list goes on), but are very interesting for an embedded device because of the the memory and/or screen real estate limitations. On the Maemo platform, for instance, this issue has been solved by having each application behave as a D-Bus service: each time an application is launched a new object on the bus is created and subsequent instances just abort. Not every embedded platform uses (or can use) D-Bus, though, hence the need for anothe IPC mechanism - like the Xlibs-based backend.
Unfortunately, hacking on libguniqueapp required pretty much the rewrite of the whole build environment; the current code base needed some cleaning up and some new feature I intended to add required a revision of the whole IPC protocol. Thus, I preferred to create a whole new library from scratch, called GtkUnique, but keeping the API pretty much the same.
The differences from GtkUnique pretty much are:
* the backend implementations have been more cleanly separated and
hidden in helper libraries;
* there's an Xlibs-based backend, which is preferred right after the
D-Bus backend;
* the IPC channel is bidirectional; that is: the message sent from a
second instance to the first instance of the application has a
return code, in case the operation that has been requested failed;
* the D-Bus backend has been changed: the name of the application is
used as the object on the bus, so you don't have awkward stuff like
org.gnome.GUniqueApp.YourApp but something a bit more friendly like
org.gnome.YourApp (implementing the org.gtk.UniqueApp interface and
the object path is /Factory);
* also in the D-Bus backend, the SendMessage message has been changed:
it now accepts a stringified command, which is the "nick" value of
the GtkUniqueCommand enum object; this way you can send commands
like 'activate' or 'new' instead of integers on the wire, in case
you want to implement the D-Bus backend from scratch.
* the GtkUniqueApp object keeps track of the top-level windows of the
application (needed for the Xlibs backend, doesn't hurt on the
other backends);
* I've added API documentation using gtk-doc;
* Perl and Python bindings are in the works;
You may think of GtkUnique as a fork of libguniqueapp; really, it's more of an experiment I wrote to get more aquainted with Xlibs and D-Bus programming. I intend to use GtkUnique inside the next release of the Dictionary and inside another couple projects of mine, so I'll keep on working on it.
If you want to play with it, just pull the bazaar repository from here:
* main trunk: bzr branch http://o-hand.com/~ebassi/bzr/gtkunique
* perl bindings: bzr branch http://o-hand.com/~ebassi/bzr/gtkunique-perl
and there's a tarball available here:
http://o-hand.com/~ebassi/gtkunique-0.1.0.tar.gz
Note on the library: the libbacon-like backend is broken at the moment, as I'm still playing with it.
Note on the bindings: I'll add the branch for the python bindings as soon as I have them in a buildable state. The Perl bindings are very rough at the moment - the "make test" phase fails and while you can send a message from a Perl application to a C application sharing the same name, you can't do the opposite.
+++
[1] http://blogs.gnome.org/view/newren/2006/08/09/1
[2] http://guniqueapp.akl.lt
[3] http://live.gnome.org/SingleInstanceApps
For the Google Summer of Code, Vytas Liuolia[1] wrote the (very much needed) guniqueapp library[2]; just a small recap: libguniqueapp allows the creation of single instance applications[3], that is applications that gets instanced once and each subsequent instance just quits - or send a command to the currently running instance.
Libguniqueapp has two available backends: D-Bus, as default, and bacon (a Un*x socket living in /tmp and used to send and receive commands). After reading about guniqueapp on desktop-devel-list, I began hacking on it in order to add a new backend, using X itself as an IPC mechanism.
Single instance applications are used on the desktop (Gedit, Mozilla, Epiphany, Evince - the list goes on), but are very interesting for an embedded device because of the the memory and/or screen real estate limitations. On the Maemo platform, for instance, this issue has been solved by having each application behave as a D-Bus service: each time an application is launched a new object on the bus is created and subsequent instances just abort. Not every embedded platform uses (or can use) D-Bus, though, hence the need for anothe IPC mechanism - like the Xlibs-based backend.
Unfortunately, hacking on libguniqueapp required pretty much the rewrite of the whole build environment; the current code base needed some cleaning up and some new feature I intended to add required a revision of the whole IPC protocol. Thus, I preferred to create a whole new library from scratch, called GtkUnique, but keeping the API pretty much the same.
The differences from GtkUnique pretty much are:
* the backend implementations have been more cleanly separated and
hidden in helper libraries;
* there's an Xlibs-based backend, which is preferred right after the
D-Bus backend;
* the IPC channel is bidirectional; that is: the message sent from a
second instance to the first instance of the application has a
return code, in case the operation that has been requested failed;
* the D-Bus backend has been changed: the name of the application is
used as the object on the bus, so you don't have awkward stuff like
org.gnome.GUniqueApp.YourApp but something a bit more friendly like
org.gnome.YourApp (implementing the org.gtk.UniqueApp interface and
the object path is /Factory);
* also in the D-Bus backend, the SendMessage message has been changed:
it now accepts a stringified command, which is the "nick" value of
the GtkUniqueCommand enum object; this way you can send commands
like 'activate' or 'new' instead of integers on the wire, in case
you want to implement the D-Bus backend from scratch.
* the GtkUniqueApp object keeps track of the top-level windows of the
application (needed for the Xlibs backend, doesn't hurt on the
other backends);
* I've added API documentation using gtk-doc;
* Perl and Python bindings are in the works;
You may think of GtkUnique as a fork of libguniqueapp; really, it's more of an experiment I wrote to get more aquainted with Xlibs and D-Bus programming. I intend to use GtkUnique inside the next release of the Dictionary and inside another couple projects of mine, so I'll keep on working on it.
If you want to play with it, just pull the bazaar repository from here:
* main trunk: bzr branch http://o-hand.com/~ebassi/bzr/gtkunique
* perl bindings: bzr branch http://o-hand.com/~ebassi/bzr/gtkunique-perl
and there's a tarball available here:
http://o-hand.com/~ebassi/gtkunique-0.1.0.tar.gz
Note on the library: the libbacon-like backend is broken at the moment, as I'm still playing with it.
Note on the bindings: I'll add the branch for the python bindings as soon as I have them in a buildable state. The Perl bindings are very rough at the moment - the "make test" phase fails and while you can send a message from a Perl application to a C application sharing the same name, you can't do the opposite.
+++
[1] http://blogs.gnome.org/view/newren/2006/08/09/1
[2] http://guniqueapp.akl.lt
[3] http://live.gnome.org/SingleInstanceApps
