Re: ToPaZ, anyone?
Thanks for these cool mockupsUnfortunately its going to be very difficult to get everyone to agree on the way forward at this stage.The best thing to do is to code up these prototypes - having workingcode is half way towards making agreement and acceptance a reality (IEits far harder to argue for something radically different if there's no code to show)just my penny for a thought...--Mr Jamie McCrackenhttp://jamiemcc.livejournal.com/ I think you're right. I'm going to gather some resources and see how far i go.-- Happy day-Brian ___ 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
