Re: LibUnique as blessed dependency
Hi, On 7/12/07, Havoc Pennington [EMAIL PROTECTED] 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 function). 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. Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: LibUnique as blessed dependency
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. this is still the reason why I left the multiple backends in. Unix domain sockets and Xlibs still guarantee the ability to implement this kind of functionality in the most portable way - via SSH forwarding, or on multiple users setups - and yet D-Bus makes the code very easy to write and expandable, and should be enough for probably the 80% of the cases we care about. libunique tries to be smart, and in the end I'd like to drop the multiple backends. Havoc and Elijah are right: this kind of functionality should be added to the toolkit; as of now, GTK+ doesn't have any application class, so it doesn't make sense to add a single instance application class without its obvious ancestor - and changing the hierarchy afterwards just for the sake of having single instance support in GTK+ now it's not an option if we want to preserve ABI and API. so, for the time being, and considering the small number of applications requiring to be single instances, and that maybe link bonobo and C. just for this, a small library is the most viable option. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: LibUnique as blessed dependency
Hi, Elijah Newren wrote: 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. I don't mean to ignore this - I agree it's needed and the hard part We did basically have this thread before I guess, I just dug out of Google my post saying the same thing I said this time, more or less: http://mail.gnome.org/archives/desktop-devel-list/2006-September/msg00470.html It would be nice IMO to go ahead and create a wiki page documenting the D-Bus interface - the Launch() thing or equivalent, and if it has a dict of properties, what the major properties are (in particular the DISPLAY, uris-to-open, and startup-notification-related properties). I think it's important for libunique to 'look right' at the raw dbus protocol level as I talked about in that September post. I'm not quite sure where to find the latest libunique code? Google is not turning it up. The multiple backends, IMO, are just historical cruft from libgunique. Thanks, this is good news. Avoiding extra complexity is always a plus! To have a discussion topic at GUADEC I started poking at a dbus convenience library called gbus that is a different angle from the various current language bindings - rather than focusing on the Object-IPC mapping and wrapping dbus/dbus.h, it just includes dbus/dbus.h wholesale and adds convenience API for things like: - tracking bus name owners as they come and go - tracking clients using an interface you provide, so you can exit when none are left - handling of bus names you own, providing the be sure there is one of me part of single instance but not the startup notification etc. part - tracking the bus itself as it comes and goes, in case you want to get ambitious and handle system bus restart This is based on hippo-dbus-helper.c which is used in the mugshot client and local-export-daemon. I'll post code sometime during GUADEC probably, I have to finish packing at the moment. Anyway, something like this (aside from being needed so dbus can be used from C without writing a ton of code), would make the IPC part of single instance super easy. The part that would remain, of course, is the gtk stuff - parsing the environment and command line options from the binary that was launched into some serializable form, and then unpacking that and doing the right magic to open on the right screen with the right startup notification in the binary that owns the single instance. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: .so versions
On 7/13/07, Murray Cumming [EMAIL PROTECTED] wrote: I've stopped changing the --version-info in gtkmm at all since a couple of years ago to avoid problems, but I'd really like a simple set of instructions about what to do in our most common cases, with examples of actual --version-info numbers before and after. Yes, this is badly needed, IMO. I've had complaints that I changed libwnck .so versions too much. But I couldn't figure it out from the comments in various configure.(ac|in) files either. Going one step further...it'd also be really nice to have some automated tool to verify whether I made the right changes. (Perhaps that could be run as part of make distcheck?) Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: .so versions
Le samedi 14 juillet 2007, à 12:01 -0600, Elijah Newren a écrit : On 7/13/07, Murray Cumming [EMAIL PROTECTED] wrote: I've stopped changing the --version-info in gtkmm at all since a couple of years ago to avoid problems, but I'd really like a simple set of instructions about what to do in our most common cases, with examples of actual --version-info numbers before and after. Yes, this is badly needed, IMO. I've had complaints that I changed libwnck .so versions too much. But I couldn't figure it out from the comments in various configure.(ac|in) files either. Here's what is in gnome-panel: # Before making a release, the LT_VERSION string should be modified. # The string is of the form C:R:A. # - If interfaces have been changed or added, but binary compatibility has # been preserved, change to C+1:0:A+1 # - If binary compatibility has been broken (eg removed or changed interfaces) # change to C+1:0:0 # - If the interface is the same as the previous version, change to C:R+1:A LIB_PANEL_APPLET_LT_VERSION=2:20:2 libwnck has some similar comments, but they're less clear (IMHO). Murray, is this set of instructions clear enough? Going one step further...it'd also be really nice to have some automated tool to verify whether I made the right changes. (Perhaps that could be run as part of make distcheck?) 100% agree. I believe some packagers are running some test to see if the API or ABI has changed. We could perhaps start from this? Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: .so versions
On Sun, 2007-07-15 at 01:05 +0200, Vincent Untz wrote: Le samedi 14 juillet 2007, à 12:01 -0600, Elijah Newren a écrit : On 7/13/07, Murray Cumming [EMAIL PROTECTED] wrote: I've stopped changing the --version-info in gtkmm at all since a couple of years ago to avoid problems, but I'd really like a simple set of instructions about what to do in our most common cases, with examples of actual --version-info numbers before and after. Yes, this is badly needed, IMO. I've had complaints that I changed libwnck .so versions too much. But I couldn't figure it out from the comments in various configure.(ac|in) files either. Here's what is in gnome-panel: # Before making a release, the LT_VERSION string should be modified. # The string is of the form C:R:A. # - If interfaces have been changed or added, but binary compatibility has # been preserved, change to C+1:0:A+1 # - If binary compatibility has been broken (eg removed or changed interfaces) # change to C+1:0:0 # - If the interface is the same as the previous version, change to C:R+1:A LIB_PANEL_APPLET_LT_VERSION=2:20:2 libwnck has some similar comments, but they're less clear (IMHO). Murray, is this set of instructions clear enough? Going one step further...it'd also be really nice to have some automated tool to verify whether I made the right changes. (Perhaps that could be run as part of make distcheck?) 100% agree. I believe some packagers are running some test to see if the API or ABI has changed. We could perhaps start from this? What I've seen a few modules do (like gtkhtml and gtksourceview) is to bump their internal versions then let pkg-config sort out the requirements. This might make a better solution for all GNOME modules rather than increasing .so versions. Shared lib versions are not reliable on all platforms. For example, on FreeBSD, the libtool code by default use the LT_CURRENT number above for the shared lib version. So while Linux will have libpanel-applet-2.so.0, FreeBSD would have libpanel-applet-2.so.2 (this gets really ridiculous when you look at something like gtk+ which can get a shared lib version of 1105 on FreeBSD). We've since hacked around this problem, but pkg-config is always unambiguous. Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: [EMAIL PROTECTED] FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
