Auto-activation of desktop-specific programs

[Kimmo Hämäläinen]

Hello,

On Tue, 2007-01-16 at 18:18 -0500, ext Havoc Pennington wrote:
> Thiago Macieira wrote:
> > I needed some comments on this proposal...
> >
> 
> Sorry, my thoughts at the time were "sounds hard, I will think about it 
> later" ;-)
> 
> >> 2) Put the .service file somewhere else and somehow make that known to
> >> dbus-daemon. We have two options:
> >>
> >> 2.a) Make it known at dbus-launch time. We have the $XDG_DATA_DIRS
> >> variable that was introduced into D-Bus's config for this exact purpose.
> >> So this option can be used right now. The cons: D-Bus mustn't be started
> >> before the actual desktop script is run (for instance, dbus-launch would
> >> be run by startkde). Also, modifying $XDG_DATA_DIRS may affect the menus
> >> too.
> >>
> >> 2.b) Make it known at run-time: we'd add a new method to
> >> org.freedesktop.DBus that would add a new path to be searched
> >> for .service files. Pros: solves the problem of starting the bus daemon.
> >> Cons: can those paths ever be removed? Can any program add them?
> >> Imagine the use-case when a program from another desktop accidentally
> >> adds its own paths.
> >>
> 
> I like 2.b fairly well. I think the cons are resolvable and the 
> implementation would be fairly simple.
> 
> We should also consider the case of "setting your preferred browser" or 
> whatever, where if the desktop knows your preferred browser it should 
> set it up to implement org.freedesktop.Browser or something. To do this, 
> perhaps in addition to adding/removing a .service directory, it could be 
> possible to specify a specific .service file by name or to specify that 
> for org.freedesktop.Browser, prefer a .service file that also offers 
> org.mozilla.Firefox (assumes Names= support I guess)

I think having a lot of different .desktop directories might lead to a
configuration mess (at least it won't make it simpler). Also, scanning
small text files in several folders does not sound very elegant solution
-- it's like having another set of init.d scripts, but in desktop-
specific directories. It also could rely on having some kind of
inotify/dnotify support to detect changes in the files.

> In general I would think of this like the "xsettings manager" where 
> there is some appointed application that has the ability to change the 
> activation settings. A simple way to do this is to add a policy to 
> session.conf saying you have to own 
> org.freedesktop.DBus.ActivationManager in order to call these methods, 
> or something like that.
> 
> There would be some race condition problems on login, if the .service 
> file path or priorities were not modified early enough in the login 
> process. This seems possible to fix though by having login block until 
> the "activation manager" finishes its configuration of the bus.
> 
> Another analogy to the "xsettings manager" is that the setting would 
> really be stored in a desktop-specific way (e.g. gconf) and the manager 
> reads and forwards that setting.
> 
> Hmm, thinking about it a bit more, adding/removing a .service directory 
> is a little worrisome; what we want to do here is prioritize what app 
> will handle a generic bus name, but if we're not careful we could also 
> make it so org.gnome.GEdit simply did not exist under KDE (for example). 
> So perhaps only reordering the .service file directories should be 
> allowed, or some kind of Environment=KDE field should be allowed in the 
> .service file and the method on the bus would let you set a list of 
> environments in priority order.
> 
> Obviously these are all half-baked thoughts, I don't know exactly how it 
> would all work out.

I was thinking something like ActivationManager, but without requiring a
dedicated manager process (separate processes are not desirable for
embedded environments). It could be done without additional .desktop
directories and without changing session.conf format: the owner of a
service could tell the daemon the name of the executable that takes
ownership of the same service. This would give flexibility for the
desktop design, for both storing the configuration (e.g. in Gconf) and
the process setup (could be separate ActivationManager, part of window
manager, etc.). The bad side is that protocol would need to be extended
so that the service could tell the daemon the executable that will take
over the service name; but the protocol extension is required also in
the other alternatives (isn't it?).

BR, Kimmo

> 
> Havoc
> 
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus