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.
* 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
Ray: well, to register the restart type, the program needs to be
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
$ strings /usr/bin/gnome-session | grep 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
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.