Right now, if bluez-pin isn't started by the user, bluez-pin can't be used (hcid should be modified to use the dbus pin helper). gnome-session 2.7.4 allows .desktop files to be dropped in a directory, so that it's started when the user logs in.
I haven't tested it, does it require adding session management support to bluez-pin, and which directory should the .desktop file be dropped in? Adding Ray to the CC. gnome-session-2.7.4-3 --------------------- * Wed Aug 18 2004 Ray Strode <rstrode redhat com> 2.7.4-3 - Change folder name from "autostart" to more aptly named "session-upgrades" from suggestion by Colin Walters. - put non-upstream gconf key in rh_extensions
the program does need to be session managed (just enough to register it's restart type) to use the drop a desktop file feature. The directory is /usr/share/gnome/session-upgrades Note that the drop a desktop file feature is just a stop gap solution to the "how do I add something to the session" problem. Hopefully, in the near future a more complete solution to all the various session management problems can be worked out.
Hmmm. Do we have to actually have dæmons running for _every_ dbus message we might want to deal with? Isn't there some way that the helper can be started automatically on demand, by registering with something dbus-related?
Ray: well, to register the restart type, the program needs to be session-managed... David: unfortunately, GNOME doesn't have a pluggable daemon like KDE does. This solution is a good stop-gap solution before the PIN helper is merged in gnome-bluetooth for example.
/usr/share/gnome/session-upgrades doesn't exist. Presumably the gnome-session package should own that directory? Is this really the way to start things? Why does nobody else do it that way?
gnome-session knows about it, and probably should own the directory, but it isn't created by default. You would just add your desktop and create the directory yourself. $ strings /usr/bin/gnome-session | grep session-upgrades session-upgrades It's definitely stop-gap. As for why other apps don't do it, they actually should, which would be a better option than adding applications to be started by hand. See http://cvs.fedora.redhat.com/viewcvs/devel/gnome-session/redhat-default-session?rev=1.4&only_with_tag=HEAD&view=auto
Honestly, the more I think about session-upgrades the less I like it. Requiring a service to be session managed was a mistake. It just adds complexity for what should be a simple thing to set up. I wish I would have never added it. This feature isn't likely to go upstream either. For now, I'd rather we just take the approach used by some of the other services at startup. Namely, starting it in main() of gnome-session. When I get time to work on libgnomeservice again these problems should all get solved of course.
So, Ray, from your last comment, could we reassign this to gnome-session and make sure that bluez-pin is started along with the rest of the desktop?
Sure. Are you trying to target FC4 for this?
Yeah, for FC4 please (the necessary bluez-pin changes are only in Rawhide).
David, I just read comment 3. The answer is "yes, dbus supports activation over the session bus". You just need to add a service file to /usr/share/dbus-1/services. That seems like a nicer solution all around. Let me reassign this to you. Feel free to ping me on irc if you need help.
My understanding is that we can't do activation over the session bus -- only over the system bus. We can't have the activated program running in the user's X session without doing evil tricks to get at the X authority file (which probably won't work with SElinux anyway).
We use /etc/xdg/autostart to run bluez-pin in the X session now anyway.