Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
Elijah Newren wrote: >> And gedit will be started if it isn't already, and reused otherwise, >> with no race conditions. > > Uh, with no race conditions affecting the number of gedit processes, I > think you mean. There's focus and workspace race conditions, unless > D-Bus launches gedit appropriately (e.g. uses > libstartup-notification). Is it possible to have D-Bus launch using > libstartup-notification? In this case I don't think that's what's wanted - instead of passing the startup notification stuff in env variables, we want to put it in the args to this Launch() method (or whatever it ends up being called). The timestamp and workspace and so forth need to come from the app invoking Launch(), not from dbus. (To answer the question yes dbus could either use libstartup-notification or do similar work, if it were needed) Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On 9/24/06, Havoc Pennington <[EMAIL PROTECTED]> wrote:
> Though I guess either way, you have essentially zero chance of getting
> this right without using libstartup-notification ... which might be the
> bigger picture point.
Actually as long as you aren't forking/execing a new process,
libstartup-notification isn't really needed anymore -- or soon won't
be (see e.g. bug 347375). The EWMH, gtk+, and metacity have been
extended a bit so that libstartup-notification is only really needed
for launching processes (and special apps like metacity and
wnck-applet) these days. Of course, if you have a single instance app
or open windows in response to messages from other applications then
you still have work to do, it's just been reduced...
> Also important to libdbus human-readability is the bus name the app
> owns, so it'd be nice to have org.gnome.GEdit rather than
> org.gnome.GUniqueApp.gedit
>
> There's a kind of impedance mismatch between dbus and some more basic
> ipc... with dbus you can have the bus launch things. So if you have a
> .service file, you can just unconditionally do:
>
> app = new Proxy("org.gnome.GEdit");
> app.Launch(uris, props);
>
> And gedit will be started if it isn't already, and reused otherwise,
> with no race conditions.
Uh, with no race conditions affecting the number of gedit processes, I
think you mean. There's focus and workspace race conditions, unless
D-Bus launches gedit appropriately (e.g. uses
libstartup-notification). Is it possible to have D-Bus launch using
libstartup-notification?
Elijah
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On 9/24/06, Alex Jones <[EMAIL PROTECTED]> wrote: > This is exactly the situation BMPx is in, too. > > It has pretty cool effects for, say, file managers, too. Consider that > gnomevfs.show_uri had the support to read a D-Bus bus-name and object > path from a .desktop file for an application, and instead of launching a > new process simply invoke the OpenURI method on the relevant interface. > Opening files just got 10 times quicker. (Try benchmarking, it really is > that much more efficient for me with Epiphany.) Sounds cool; I'm all in favor. Let's just make sure it works with timestamps, workspaces and other general startup-notification stuff. :-) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On 9/24/06, Alex Jones <[EMAIL PROTECTED]> wrote: > On Sun, 2006-09-24 at 09:13 -0400, Owen Taylor wrote: > > Is "extensible" compatible with hiding the gory details of start-up > > notification timestamps? I don't know. I don't have a good sense > > of what a prototypical D-Bus exporting application looks like. Although timestamps are important, note that they are only part of handling startup-notification. I think we can almost make "extensible" compatible with hiding the gory details of startup-notification; the main thing is we just need an extra slot in the dbus messages for sending the relevant startup-notification/launch information. We could write some kind of gtk_get_important_launch_info(&launch_info); function to be called on the sending side, make sure the dbus message includes launch_info, and then have the receving side call gtk_window_associate_with_data(window, launch_info); before showing the relevant window. Here I'm suggesting gtk_window_associate_with_data() as a replacement for gtk_window_set_startup_id() (from bug 347375); I think assocate_with_data generalizes it for the new stuff Alex is proposing and I think future-proofs it a little bit more. > I've been dodging the issue of startup-notification just because I don't > really fully understand it. I figure that solutions for these kind of > issues are just things you can bolt on. That's what I was afraid of. You can't. To solve these issues, you need data from the "launching" process., meaning that you have to send extra information along with your messages. This is true for both the launch-an-actual-second-process-of-said-app case (what GUnique currently handles as part of the second-process) as well as the send-specified-dbus-message-to-said-app case (which you are proposing). Please include an extra slot in your message proposal to allow this. > > What I've seen tends to be a bit messy, especially in C. To say the least. :) There were a few reasons for this -- (1) metacity & gtk+ previously didn't have sufficient support to make things simpler (which was was partially a reflection of the spec at the time), (2) we made apps handle all the gory details themselves, and (3) apps actually had to work around gtk+ in various ways (e.g. to actually obtain the startup notification information since gtk+ grabbed it and hid it). Cheers, Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
(Crap, *sends to list this time round*) On Sun, 2006-09-24 at 23:28 +0100, Gustavo J. A. M. Carneiro wrote: > Dom, 2006-09-24 às 16:57 +0100, Alex Jones escreveu: > > On Sun, 2006-09-24 at 09:43 -0600, Elijah Newren wrote: > > > > > > GUnique already uses D-Bus (with bacon as a backup). So, how is your > > > proposal different than GUnique? (Other than startup-notification not > > > being mentioned in your proposal yet?) > > > > It's different because it separates the process starts the service from > > the process that invokes methods on the service (i.e. LaunchNew(), > > OpenURI(), etc.). > > I completely agree that separating the "client interface" from the > main app is beneficial. Witness Rhythmbox that recently started > shipping a lightweight rhythmbox-client program that allows one to > control RB without loading a very large binary in the process. Now I > can bind my multimedia keys to control RB without having to wait a few > seconds before pressing a key takes effect. This is exactly the situation BMPx is in, too. It has pretty cool effects for, say, file managers, too. Consider that gnomevfs.show_uri had the support to read a D-Bus bus-name and object path from a .desktop file for an application, and instead of launching a new process simply invoke the OpenURI method on the relevant interface. Opening files just got 10 times quicker. (Try benchmarking, it really is that much more efficient for me with Epiphany.) > > > It also gives us the ability to pre-load applications without showing > > any interface. I am totally willing to spare a chunk of my RAM if it > > means I don't have to keep warm-starting Epiphany every time I open a > > web page. It would make my entire desktop use a whole lot more > > responsive. > > +1 > -- Alex Jones <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
Elijah Newren wrote:
>> http://live.gnome.org/DesktopAppsAsDBusServices
>>
>> (Crappy write-up, but I just haven't had time to sort it out. Sorry!)
>
> GUnique already uses D-Bus (with bacon as a backup). So, how is your
> proposal different than GUnique? (Other than startup-notification not
> being mentioned in your proposal yet?)
>
A nice thing in that writeup is that the dbus usage is more "human
readable", libgunique is basically using dbus as a complicated socket:
http://cvs.gnome.org/viewcvs/libguniqueapp/libguniqueapp/guniqueapp-dbus.c?rev=1.2&view=markup
It does:
interface GUniqueAppInterface {
bool SendMessage(int command, String data, String startup_id,
unsigned int workspace);
}
(implemented by object /Factory, where command is an enum { ACTIVATE,
NEW, OPEN, CUSTOM })
The "clean" way to do it I think might be something like:
interface UniqueApplication {
void Open(Array uris, Dict properties);
void New(...);
void Activate(...);
}
Where e.g. the startup notification stuff is in the properties. Really
the uris could also be in the properties, just figuring that's the most
common property. Anyway, the exact interface isn't the point just that
it has methods for each operation instead of a single SendMessage.
maybe something like:
interface Launchable {
void Launch(Array uris, Dict properties);
}
(dbus convention nitpicks: no "Interface" or "IFace" in interface name,
namespace /org/gnome on object path, lowercase object path, exceptions
rather than boolean return, no need for GUnique namespace in interface
name since the interface already has org.gnome.)
Anyway, if you think about e.g. Python scripting, it's going to be a bit
nicer to say something like
app.Launch(uri)
than
app.SendMessage(2, uri)
(imagine if all dbus APIs looked like the second one)
Though I guess either way, you have essentially zero chance of getting
this right without using libstartup-notification ... which might be the
bigger picture point.
Also important to libdbus human-readability is the bus name the app
owns, so it'd be nice to have org.gnome.GEdit rather than
org.gnome.GUniqueApp.gedit
There's a kind of impedance mismatch between dbus and some more basic
ipc... with dbus you can have the bus launch things. So if you have a
.service file, you can just unconditionally do:
app = new Proxy("org.gnome.GEdit");
app.Launch(uris, props);
And gedit will be started if it isn't already, and reused otherwise,
with no race conditions.
This also works with methods other than Launch, so say the app has a
method like SpellCheck, you can do:
app = new Proxy("org.gnome.GEdit");
results = app.SpellCheck(stuff);
It's a stupid example but you get the idea...
Anyhow, one thing that is enabled here would be something like this in
the .desktop file:
DBus-Launchable=org.gnome.GEdit
Exec=dbus-send-to-launchable org.gnome.GEdit %u
Where the point is that the Exec= line is for backward compat, but the
panel or whatever could also just invoke the Launch method on
org.gnome.GEdit directly, i.e. the DBus-Launchable= field means that the
bus name supports the standard UniqueApp/Launchable interface.
Not sure that's really worth doing, but I guess an observation is that
with dbus the "client" mode can just be generic, because the client
doesn't have to be able to become the factory - the bus can start a
factory. While with gunique right now, I believe the assumption is that
the launching app is the same app that's being launched and can thus
become the factory if there isn't a factory yet. Third parties have to
launch by fork/exec rather than by invoking a dbus method.
Havoc
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
Dom, 2006-09-24 às 16:57 +0100, Alex Jones escreveu: > On Sun, 2006-09-24 at 09:43 -0600, Elijah Newren wrote: > > > > GUnique already uses D-Bus (with bacon as a backup). So, how is your > > proposal different than GUnique? (Other than startup-notification not > > being mentioned in your proposal yet?) > > It's different because it separates the process starts the service from > the process that invokes methods on the service (i.e. LaunchNew(), > OpenURI(), etc.). I completely agree that separating the "client interface" from the main app is beneficial. Witness Rhythmbox that recently started shipping a lightweight rhythmbox-client program that allows one to control RB without loading a very large binary in the process. Now I can bind my multimedia keys to control RB without having to wait a few seconds before pressing a key takes effect. > It also gives us the ability to pre-load applications without showing > any interface. I am totally willing to spare a chunk of my RAM if it > means I don't have to keep warm-starting Epiphany every time I open a > web page. It would make my entire desktop use a whole lot more > responsive. +1 -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On Sun, 2006-09-24 at 09:13 -0400, Owen Taylor wrote: > On Sun, 2006-09-24 at 09:43 -0600, Elijah Newren wrote: > > > > (Crappy write-up, but I just haven't had time to sort it out. Sorry!) > > > > GUnique already uses D-Bus (with bacon as a backup). So, how is your > > proposal different than GUnique? (Other than startup-notification not > > being mentioned in your proposal yet?) > > One thing that a hard dependency on D-Bus could provide is more ability > to extend the mechanism to provide for additional application needs. > > A generic mechanism can provide handle the needs of gnome-terminal or > gedit; but not every command that you might want to pass to a desktop > singleton is "open a new window". > > I think it would be a little strange from an API point of view to have > to do one thing (GUnique) to get "open a new window" functionality, > and then entirely something else to get "scriptable singleton" > functionality. > > Is "extensible" compatible with hiding the gory details of start-up > notification timestamps? I don't know. I don't have a good sense > of what a prototypical D-Bus exporting application looks like. I've been dodging the issue of startup-notification just because I don't really fully understand it. I figure that solutions for these kind of issues are just things you can bolt on. I may be vastly underestimating the complexity of s-n, though. > > What I've seen tends to be a bit messy, especially in C. > > - Owen > > > -- Alex Jones <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On Sun, 2006-09-24 at 09:43 -0600, Elijah Newren wrote: > > (Crappy write-up, but I just haven't had time to sort it out. Sorry!) > > GUnique already uses D-Bus (with bacon as a backup). So, how is your > proposal different than GUnique? (Other than startup-notification not > being mentioned in your proposal yet?) One thing that a hard dependency on D-Bus could provide is more ability to extend the mechanism to provide for additional application needs. A generic mechanism can provide handle the needs of gnome-terminal or gedit; but not every command that you might want to pass to a desktop singleton is "open a new window". I think it would be a little strange from an API point of view to have to do one thing (GUnique) to get "open a new window" functionality, and then entirely something else to get "scriptable singleton" functionality. Is "extensible" compatible with hiding the gory details of start-up notification timestamps? I don't know. I don't have a good sense of what a prototypical D-Bus exporting application looks like. What I've seen tends to be a bit messy, especially in C. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On Sun, 2006-09-24 at 09:43 -0600, Elijah Newren wrote: > On 9/24/06, Alex Jones <[EMAIL PROTECTED]> wrote: > > Hi, list > > > > As an alternative to GUnique, you could do the kind of thing Maemo does > > just by using D-Bus. > > If "just by using D-Bus" means what I think it does, then all desktop > apps doing so are broken. You need to handle startup-notification too > (gtk+ tries to handle startup-notification details for apps, but > single-instance apps do things behind gtk+'s back in order to be > single instance and thus require extra work). > > > http://live.gnome.org/DesktopAppsAsDBusServices > > > > (Crappy write-up, but I just haven't had time to sort it out. Sorry!) > > GUnique already uses D-Bus (with bacon as a backup). So, how is your > proposal different than GUnique? (Other than startup-notification not > being mentioned in your proposal yet?) It's different because it separates the process starts the service from the process that invokes methods on the service (i.e. LaunchNew(), OpenURI(), etc.). It also gives us the ability to pre-load applications without showing any interface. I am totally willing to spare a chunk of my RAM if it means I don't have to keep warm-starting Epiphany every time I open a web page. It would make my entire desktop use a whole lot more responsive. Hope this clears things up. > > Elijah -- Alex Jones <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On 9/24/06, Alex Jones <[EMAIL PROTECTED]> wrote: > Hi, list > > As an alternative to GUnique, you could do the kind of thing Maemo does > just by using D-Bus. If "just by using D-Bus" means what I think it does, then all desktop apps doing so are broken. You need to handle startup-notification too (gtk+ tries to handle startup-notification details for apps, but single-instance apps do things behind gtk+'s back in order to be single instance and thus require extra work). > http://live.gnome.org/DesktopAppsAsDBusServices > > (Crappy write-up, but I just haven't had time to sort it out. Sorry!) GUnique already uses D-Bus (with bacon as a backup). So, how is your proposal different than GUnique? (Other than startup-notification not being mentioned in your proposal yet?) Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
Hi, list As an alternative to GUnique, you could do the kind of thing Maemo does just by using D-Bus. http://live.gnome.org/DesktopAppsAsDBusServices (Crappy write-up, but I just haven't had time to sort it out. Sorry!) On Sun, 2006-09-24 at 16:07 +0100, Emmanuele Bassi wrote: > Hi; > > On Sun, 2006-09-24 at 13:47 +0200, Marco Barisione wrote: > > Emmanuele Bassi wrote: > > > >> On Windows AF_UNIX is not available, but Windows has named pipes that > > >> are more similar to sockets than to Unix named pipes. However only the > > >> client part of named pipes is supported on Windows 9x/Me. > > > > > > Single instance applications on Windows NT/XP use the named mutex > > > pattern[1], to which we can provide a nice wrapper using GUnique I > > > think. > > > > I know but GUniqueApp requires communication between the "server" and > > the "client", using named mutex you can't communicate. > > Mmmh, right. > > > > I think we can use a platform-based approach: > > > > > > * D-Bus, Xlibs and bacon on *nix on a soft dependency basis; > > > * bacon on OS X; > > > * named mutex and bacon on win32. > > > > Bacon on win32? > > With modification for using sockets on win32 instead of a named pipe. > > Ciao, > Emmanuele. > -- Alex Jones <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
Hi; On Sun, 2006-09-24 at 13:47 +0200, Marco Barisione wrote: > Emmanuele Bassi wrote: > >> On Windows AF_UNIX is not available, but Windows has named pipes that > >> are more similar to sockets than to Unix named pipes. However only the > >> client part of named pipes is supported on Windows 9x/Me. > > > > Single instance applications on Windows NT/XP use the named mutex > > pattern[1], to which we can provide a nice wrapper using GUnique I > > think. > > I know but GUniqueApp requires communication between the "server" and > the "client", using named mutex you can't communicate. Mmmh, right. > > I think we can use a platform-based approach: > > > > * D-Bus, Xlibs and bacon on *nix on a soft dependency basis; > > * bacon on OS X; > > * named mutex and bacon on win32. > > Bacon on win32? With modification for using sockets on win32 instead of a named pipe. Ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] 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: GUnique [Was: gnome-utils branched for GNOME 2.16]
Emmanuele Bassi wrote: >>> Is this API appropriate for GTK+ and adaptable for use with Windows >>> and OS X? >> OS X could use the bacon backend (that uses Unix domain sockets). >> >> On Windows AF_UNIX is not available, but Windows has named pipes that >> are more similar to sockets than to Unix named pipes. However only the >> client part of named pipes is supported on Windows 9x/Me. > > Single instance applications on Windows NT/XP use the named mutex > pattern[1], to which we can provide a nice wrapper using GUnique I > think. I know but GUniqueApp requires communication between the "server" and the "client", using named mutex you can't communicate. > I think we can use a platform-based approach: > > * D-Bus, Xlibs and bacon on *nix on a soft dependency basis; > * bacon on OS X; > * named mutex and bacon on win32. Bacon on win32? -- Marco Barisione http://www.barisione.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On 9/23/06, Steve Frécinaux <[EMAIL PROTECTED]> wrote: > Jeff Waugh wrote: > > Can we use it as-is (or as well-defined cut'n'paste code) in GNOME 2.18 and > > plan towards migrating to a GTK+ 2.12 version in GNOME 2.20? Let's at least > > have a plan for it, otherwise we're just adding yet another [as above] with > > little active thought for our users, distributors and platform consumers. > > Mh, why would it target GTK+ and not Glib ? I'm asking this because such > a "Unique Instance" stuff would also be useful for daemons that > (obviously) shouldn't link with GTK+ since there is usually no UI for > those... There's a lot of window manager interaction that needs to be done for GUI apps to ensure that startup-notification works properly. GUnique needs to make use of both gdk and gtk calls to make sure things work properly (not to mention it has to employ hacky workarounds until the patch in bug 347375 is incorporated into gdk & gtk). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
Jeff Waugh wrote: > Can we use it as-is (or as well-defined cut'n'paste code) in GNOME 2.18 and > plan towards migrating to a GTK+ 2.12 version in GNOME 2.20? Let's at least > have a plan for it, otherwise we're just adding yet another [as above] with > little active thought for our users, distributors and platform consumers. Mh, why would it target GTK+ and not Glib ? I'm asking this because such a "Unique Instance" stuff would also be useful for daemons that (obviously) shouldn't link with GTK+ since there is usually no UI for those... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On Sat, 2006-09-23 at 19:39 +0200, Marco Barisione wrote: > Jeff Waugh wrote: > > Is this API appropriate for GTK+ and adaptable for use with Windows > > and OS X? > > OS X could use the bacon backend (that uses Unix domain sockets). > > On Windows AF_UNIX is not available, but Windows has named pipes that > are more similar to sockets than to Unix named pipes. However only the > client part of named pipes is supported on Windows 9x/Me. Single instance applications on Windows NT/XP use the named mutex pattern[1], to which we can provide a nice wrapper using GUnique I think. I think we can use a platform-based approach: * D-Bus, Xlibs and bacon on *nix on a soft dependency basis; * bacon on OS X; * named mutex and bacon on win32. > If we want to support Windows 9x/Me we could use mailslots[1] or plain > sockets. since GTK+ HEAD dropped support for 9x/ME, if GUnique is slated to be integrated into GTK+ I think we can safely assume that 9x/ME are an unsupported platform. +++ [1] http://windowssdk.msdn.microsoft.com/en-us/library/ms682418.aspx Ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] 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: GUnique [Was: gnome-utils branched for GNOME 2.16]
Jeff Waugh wrote: > Is this API appropriate for GTK+ and adaptable for use with Windows > and OS X? OS X could use the bacon backend (that uses Unix domain sockets). On Windows AF_UNIX is not available, but Windows has named pipes that are more similar to sockets than to Unix named pipes. However only the client part of named pipes is supported on Windows 9x/Me. If we want to support Windows 9x/Me we could use mailslots[1] or plain sockets. [1] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/about_mailslots.asp -- Marco Barisione http://www.barisione.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On Fri, 2006-09-22 at 05:49 -0400, Richard Hughes wrote: > So I propose, tell maintainers to link against linguniqueapp (as it's > more sane that what we have already[1]) and then depreciate it in a > couple of years time when we've decided where it belongs. This means > maintainers like me get single-instance support *now*. It also means that even with deprecation, it will be used and shipped around for years to come, just because someone doesn't like depending on Gtk+ 2.12, or have not converted, or whatever. Copy/pasting is a superior solution if we know the code is going to be merged soonish. -- behdad http://behdad.org/ "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill" -- Dan Bern, "New American Language" ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On Fri, 2006-09-22 at 02:12 -0600, Elijah Newren wrote: > On 9/22/06, Alexander Larsson <[EMAIL PROTECTED]> wrote: > > Uhm? Why not use X for IPC? > > *shrug* I remember that we (Matthias, Vytas, and I) discussed D-Bus, > Bonobo, and Bacon (since there were several Gnome applications using > each of those for their single-instance mechanism) and X (which > Matthias brought up and also since Mozilla/Firefox uses it for its > single-instance mechanism). However, I no longer recall any details > about this particular choice since I was more interested in the WM > interaction details (surprise, surprise). It may have been that Vytas > was familiar with D-Bus and Bacon and we figured it was more important > to get other details worked out first, but I just don't remember. > > However, Vytas did design GUnique to make the backend easy to > transparently replace. I frequently use XNest at work. Some of the builds I have to run automatically open and close hundreds of windows. So I run the builds inside XNest, and I don't have to look at all those windows popping up on my screen. If I try to open an application inside XNest that I already have available outside XNest, and if that application uses one of our existing single-instance schemes (like bonobo), I get another window *outside* the XNest, which is annoying. Using X for IPC would, presumably, solve this. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
Alexander Larsson wrote: > One advantage of using X would be that it works for remote X clients > too. > I think it'd be a mistake to start using X for all ipc for that reason - you'd end up never using dbus, and X is kind of a sucky IPC. To solve this for dbus there are two basic approaches, one is to make ssh forward DBUS_SESSION_BUS_ADDRESS and have the session bus listen on tcp, the other is to write an X11 transport that tunnels a bus connection through X. Neither is very hard in theory though I grant neither is already done. The dbus bus name stuff is essentially designed for the unique app use-case - though, I grant it's modeled on X selections which are also essentially designed for this use-case. Either way, I think it's important to make the bus name or X selection name look "sane" when not used through the GUnique interface, i.e. on dbus the bus name for Evolution should be something like "org.gnome.Evolution" and on X the selection name should be something like "_GNOME_EVOLUTION_INSTANCE" (btw, in both cases a --replace mode would be nice, especially for debugging, and is natively/easily supported) Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
Hi; On Fri, 2006-09-22 at 13:49 +0200, Alexander Larsson wrote: > > *shrug* I remember that we (Matthias, Vytas, and I) discussed D-Bus, > > Bonobo, and Bacon (since there were several Gnome applications using > > each of those for their single-instance mechanism) and X (which > > Matthias brought up and also since Mozilla/Firefox uses it for its > > single-instance mechanism). However, I no longer recall any details > > about this particular choice since I was more interested in the WM > > interaction details (surprise, surprise). It may have been that Vytas > > was familiar with D-Bus and Bacon and we figured it was more important > > to get other details worked out first, but I just don't remember. > > > > However, Vytas did design GUnique to make the backend easy to > > transparently replace. > > One advantage of using X would be that it works for remote X clients > too. Right now, GUniqueApp depends on a compile-time check for D-Bus and a run-time check between D-Bus (if support was compiled in) and Bacon (as a fallback). In order to add it to GTK+ a Xlib default IPC should be used[1], and I'd suggest to use modules loadable at run-time for the other transports, like D-Bus. We'd also have to use something on win32 and OSX, even though I think that other platforms already have facilities for this kind of stuff. +++ [1] We could define a spec with some default properties, like: _G_UNIQUE_VERSION integer, in form 0x%02d%02d%02d _G_UNIQUE_NAMEUTF-8 string _G_UNIQUE_STARTUP_ID string _G_UNIQUE_COMMAND integer _G_UNIQUE_DATAstring which maps the protocol used by the current GUniqueApp implementation as far as I can see. The _VERSION property could be used for versioning, in case we'd add some new commands. Ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] 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: GUnique [Was: gnome-utils branched for GNOME 2.16]
On Fri, 2006-09-22 at 02:12 -0600, Elijah Newren wrote: > On 9/22/06, Alexander Larsson <[EMAIL PROTECTED]> wrote: > > Uhm? Why not use X for IPC? > > *shrug* I remember that we (Matthias, Vytas, and I) discussed D-Bus, > Bonobo, and Bacon (since there were several Gnome applications using > each of those for their single-instance mechanism) and X (which > Matthias brought up and also since Mozilla/Firefox uses it for its > single-instance mechanism). However, I no longer recall any details > about this particular choice since I was more interested in the WM > interaction details (surprise, surprise). It may have been that Vytas > was familiar with D-Bus and Bacon and we figured it was more important > to get other details worked out first, but I just don't remember. > > However, Vytas did design GUnique to make the backend easy to > transparently replace. One advantage of using X would be that it works for remote X clients too. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a maverick vegetarian photographer on his last day in the job. She's a blind communist hooker who hides her beauty behind a pair of thick-framed spectacles. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On Thu, 2006-09-21 at 19:36 -0600, Elijah Newren wrote: > I agree that we don't really want another shared library, long term. > Luckily, it should be easy to update apps when GUnique becomes part of > some other library, as the code required to use GUnique is pretty > small. As to how we get there, though, Matthias and others with more > knowledge of the platform stack will need to comment. First, sorry for branching the thread. If we use linguniqueapp as a shared library we can use it in applications now (2.17), and during the 2.18 cycle. If libguniqueapp is included in gtk+ at some state (and GNOME depends on this new version) then I think it is very sane to "convert" apps to use the new gtk feature and depreciate libguniqueapp. Think like eggtrayicon to GtkStatusIcon, only less copy and paste ;-) I also think one of the reasons it was not written with gtk+ as a target was the "level choice" i.e. does this stuff belong in gtk+, libgnome, or some other module. So I propose, tell maintainers to link against linguniqueapp (as it's more sane that what we have already[1]) and then depreciate it in a couple of years time when we've decided where it belongs. This means maintainers like me get single-instance support *now*. Just my opinion tho. Richard. [1] Which are lots of hacks IMO. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On 9/22/06, Alexander Larsson <[EMAIL PROTECTED]> wrote: > Uhm? Why not use X for IPC? *shrug* I remember that we (Matthias, Vytas, and I) discussed D-Bus, Bonobo, and Bacon (since there were several Gnome applications using each of those for their single-instance mechanism) and X (which Matthias brought up and also since Mozilla/Firefox uses it for its single-instance mechanism). However, I no longer recall any details about this particular choice since I was more interested in the WM interaction details (surprise, surprise). It may have been that Vytas was familiar with D-Bus and Bacon and we figured it was more important to get other details worked out first, but I just don't remember. However, Vytas did design GUnique to make the backend easy to transparently replace. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
> Uhm? Why not use X for IPC? Because clearly you would be hit by a bus if you considered such outrageous notions. - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ "Whatcha wanna be when you grow up?" "Eight and a half." ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On Thu, 2006-09-21 at 19:36 -0600, Elijah Newren wrote: > On 9/21/06, Jeff Waugh <[EMAIL PROTECTED]> wrote: > > Before recommending that everyone use GUnique, could we define a > > migration path for it to enter the platform? We really don't need yet > > another > > shared library, and yet another module to release, and yet another separate > > API to learn. Is this API appropriate for GTK+ and adaptable for use with > > Windows and OS X? > > > > Can we use it as-is (or as well-defined cut'n'paste code) in GNOME 2.18 and > > plan towards migrating to a GTK+ 2.12 version in GNOME 2.20? Let's at least > > have a plan for it, otherwise we're just adding yet another [as above] with > > little active thought for our users, distributors and platform consumers. > > You're asking all the right questions. Unfortunately, I don't have > complete answers. > > IIRC (which is questionable), the biggest potential issue with it > being in GTK+ was its IPC mechanism. In fact, Vytautas decided to put > two IPC mechanisms into it partially because of this (Matthias was not > sure GTK+ was ready to depend on D-Bus yet, so Vytas made it possible > to use either D-Bus or Bacon, chosen at compile time). Uhm? Why not use X for IPC? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a benighted drug-addicted gangster fleeing from a secret government programme. She's a pregnant streetsmart soap star from a secret island of warrior women. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On 9/21/06, Jeff Waugh <[EMAIL PROTECTED]> wrote: > Before recommending that everyone use GUnique, could we define a > migration path for it to enter the platform? We really don't need yet another > shared library, and yet another module to release, and yet another separate > API to learn. Is this API appropriate for GTK+ and adaptable for use with > Windows and OS X? > > Can we use it as-is (or as well-defined cut'n'paste code) in GNOME 2.18 and > plan towards migrating to a GTK+ 2.12 version in GNOME 2.20? Let's at least > have a plan for it, otherwise we're just adding yet another [as above] with > little active thought for our users, distributors and platform consumers. You're asking all the right questions. Unfortunately, I don't have complete answers. IIRC (which is questionable), the biggest potential issue with it being in GTK+ was its IPC mechanism. In fact, Vytautas decided to put two IPC mechanisms into it partially because of this (Matthias was not sure GTK+ was ready to depend on D-Bus yet, so Vytas made it possible to use either D-Bus or Bacon, chosen at compile time). I agree that we don't really want another shared library, long term. Luckily, it should be easy to update apps when GUnique becomes part of some other library, as the code required to use GUnique is pretty small. As to how we get there, though, Matthias and others with more knowledge of the platform stack will need to comment. Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GUnique [Was: gnome-utils branched for GNOME 2.16]
> Um, oops... Richard just pointed out to me how I had forgotten that Vytas > had done a very good job making the GUnique library work as well as > possible with gtk+-2.10. So, you can still implement it this cycle. Some > notes: > > 1) Richard has imported the GUnique library as libgunique in cvs; he has > been applying some patches to improve it and will be applying some more > (e.g. to make it a shared library). Before recommending that everyone use GUnique, could we define a migration path for it to enter the platform? We really don't need yet another shared library, and yet another module to release, and yet another separate API to learn. Is this API appropriate for GTK+ and adaptable for use with Windows and OS X? Can we use it as-is (or as well-defined cut'n'paste code) in GNOME 2.18 and plan towards migrating to a GTK+ 2.12 version in GNOME 2.20? Let's at least have a plan for it, otherwise we're just adding yet another [as above] with little active thought for our users, distributors and platform consumers. Thanks, - Jeff -- Ohio LinuxFest 2006: Columbus OH, USA http://www.ohiolinux.org/ "Laughter is a force for democracy." - John Cleese ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
