Re: LibUnique as blessed dependency

[Alex Jones <alex weej com>]

(See also other reply)

As far as Launch vs. NewDocument vs. OpenDocument is concerned, We can
finally support XDG Desktop Actions[1] on files by implementing
different methods for opening files.

I suggest using a common method, say,
(org.gnome.Application).FileAction(string action, string URI), and then
registering action strings with descriptions in the desktop file. The
alternative is to register the actual DBus method names, but that would
mean creating separate methods for each action, and duplicating things
like the method signature, etc.

[1] Of course, they wouldn't actually be XDG Actions, because we're not
forking a process, but rather invoking a DBus method on an object. But
the end result is the same, and still massively useful.

Normal "Launch" procedure can be done with a
(org.gnome.Application).Launch(), as this does not involve acting on any
files.

On Thu, 2007-07-12 at 14:07 -0400, Havoc Pennington wrote:
> Hi,
> 
> Is libunique really the right approach? To me, I think there are two 
> approaches I would consider:
> 
> 1) a cross-platform API in GTK using Xlib (via X selections) on Linux 
> and whatever on Windows, so this is cross platform and no dependencies.
> I guess the cross-platform API in GTK could also use D-Bus if it jumped 
> through the right hoops to make it optional or something.
> 
> 2) an addition to whatever D-Bus binding people are using that makes it 
> simpler to do "single instance" with a dbus bus name
> As I wrote in http://log.ometer.com/2006-11.html:
> 
>     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.)
> 
> 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.
> 
> It seems like too small a piece of functionality to have in a separate 
> library, especially if there aren't multiple backends.
> 
> I think I had some other comments on the bug report too, e.g. about 
> having stuff in gtk so that running the first time looks identical to 
> the app vs. running the second time (basically have main() just set up a 
> callback, which is then called for both the first and subsequent 
> launches), but the above is the macro point.
> 
> A real advantage of saying D-Bus is the one true way, rather than having 
> a configurable backend, is that you don't HAVE to use a C library. If 
> you're using python and D-Bus is simple to use, then to run the app 
> org.gnome.MyAppName you just do a thing like:
>   proxy = dbus.whateverthemethodiscalled('org.gnome.MyAppName')
>   proxy.NewDocument()
> 
> A second real advantage is that arbitrary new commands can be supported, 
> not just NewDocument() or Launch() or whatever the main single-instance 
> command is.
> 
> libgtkunique at least used to have a way to do multiple commands, but it 
> was kind of a limited and ad hoc IPC system; why not just _use_ the IPC 
> system we have?
> 
> We can also ship a small binary with dbus that does something like:
> 
>   - takes a command line arg which is the dbus bus name of the app
>   - parse command line args such as --display
>   - grab startup notification stuff from environment
>   - stuff all of the above in a dictionary_of_stuff
>   - call a Launch(dictionary_of_stuff) method on org.gnome.MyAppName
> 
> Call this dbus-app-starter or something. So you use it like:
> 
>   dbus-app-starter org.gnome.MyAppName --display :0.1 --other-arg
> 
> So the way you do a single-instance app is:
>   - ship a .service file that runs your app (probably you put the
>     app itself in libexecdir)
>   - ship a .desktop file that has an exec line:
>      dbus-app-starter org.gnome.MyAppName
>   - optionally, install to /usr/bin a script that just runs
>     dbus-app-starter, so people have a friendly name for your
>     app to type in a terminal
> 
> If you want your app to support custom commands, you just support 
> methods other than Launch() that do whatever you want.
> 
> The right standard method might not be Launch(), it might be 
> OpenDocument() or NewDocument() or something like that, or maybe all of 
> the above.
> 
> To supplement dbus-app-starter you'd also need functionality in GTK or 
> other library to handle the incoming Launch() method call and set up 
> startup notification etc. using the info in the dictionary.
> 
> Going a bit broader in scope, our D-Bus usage is all over the map and 
> needs more structure; the bindings or some convenience API needs to 
> support common operations such as:
>   - taking action whenever a particular service appears
>   - single-instance using a bus name
>   - keeping track of "who is using my service" in order to send
>     them callbacks or decide whether to exit
> 
> I've thought about writing a little library for this stuff (there is a 
> hippo-dbus-helper.c cut-and-pasted to a couple online-desktop modules 
> already). If we did this then it seems like unique app functionality 
> could be in a combination of this library and GTK.
> 
> Anyway, I don't want to slow anyone down and if people want unique app 
> functionality now I guess we should use the work that's been done, but I 
> did want to say my piece rather than complain after it's too late.
> 
> Havoc
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
-- 
Alex Jones
http://alex.weej.com/