Re: LibUnique as blessed dependency


On 7/12/07, Havoc Pennington <hp redhat com> wrote:
    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.)

I think you're still mostly ignoring a big part of the puzzle.  IMO,
D-Bus (as it exists today) is not a complete solution for this
problem.  I do not recall yet seeing an application author of a
single-instance application (whether they used D-Bus, X, bonobo,
bacon, or something else) try to handle startup-notification on their
own and get it right.  Maybe there was such a case and I missed it or
forgot it, but I've seen dozens of apps get it wrong in various ways
and plenty of others just not even attempt to get things right.

Thus, I feel that any library for single-instance applications which
does not intrinsically handle startup-notification (e.g. D-Bus as it
stands today) cannot be considered a complete solution.  In fact,
startup-notification handling and simplifying it for apps was the
major thrust of the work for the original libgunique and is IMO the
whole point of the library (well, that and determining the necessary
patches to gtk+ and metacity to enable such a library to exist and

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.

The multiple backends, IMO, are just historical cruft from libgunique.
They reflect an inability of ours at the time to determine what the
right thing to use was. (Note that D-Bus was not stable at the time)
Vytautas, Matthias, and I figured that we'd eventually decide on just
one but figured it was easiest to just forge ahead trying to get a
proof of concept for whatever might ultimately be used.

So yeah, I don't think the multiple backends make sense going forward.
I also like your ideas about the dbus-launcher, particularly avoiding
the extra forks/execs (didn't someone else bring this up a while ago
too?).  Sounds cool.

Anyway, just my $0.02.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]