Red Hat Bugzilla – Bug 247284
bluez-gnome's autostart .desktop file fails to start under a KDE session
Last modified: 2007-11-30 17:12:09 EST
Description of problem:
The blues-gnome applet fails to open when starting a KDE session. As far as I
know, this will be changed via a patch, allowing KDE to look in
$XDG_CONFIG_DIRS/autostart (/etc/xdg/autostart). I've made some minor changes
to bluetooth-applet.desktop to allow it to start successfully under a KDE
Steps to Reproduce:
1. Start a KDE session
Note that the foo.desktop files placed in /etc/xdg/autostart aren't seen when
KDE starts and the apps they reference are not started. Moving them to a
location where they are seen by a KDE session results in undesirable behavior.
The desktop files in the system-wide autostart directory should start without
The attached patch adds:
StartupNotify allows the applet to start under a KDE session without
displaying KDE's app start up notification icon.
X-KDE-autostart-after=panel allows the applet to start after KDE's panel
(kicker), preventing a race between the panel and the applet.
Lastly, the desktop file's 'Categories=' entry was empty. I've added some
useful entries for consistency with the other desktop files found in the
Created attachment 158675 [details]
Patch allowing bluez-gnome's autostart file to start as expected under a KDE session
Those seem to make some sense. But why would it *fail* to start under KDE
Sorry, I should have made things more clear. As it stands right now, KDE 3.x.x
doesn't implement the XDG autostart specification and therefore won't open
desktop files placed in /etc/xdg/autostart. I've spoken with Rex Dieter about
this and it was decided at a recent SIG meeting that KDE would be patched to
rectify the problem. I've filed bugs against the packages I have installed
that place desktop files in this directory. The bug description is meant to be
general and in anticipation of the patch to KDE.
I should say the applet fails to start amicably if the files are placed in one
of KDE's autostart directories ($KDEDIRS/autostart and $KDEHOME/Autostart)
without those two entries. Without StartupNotify, KDE's user-visible
application start notification(s) are displayed, which is undesirable for an
automatically started systray applet. Without X-KDE-autostart-after=panel, the
applet may fully open before the panel.
Ha! so it still works, but doesn't look good, right?
If so, I'll push it upstream (minus the Categories changes which I don't think
are useful at all).
Right. Great, thanks. Yeah, it doesn't appear in any menus. I guess I got a
bit carried away while reading the desktop menu spec.
We'll pick it up in the next version of bluez-gnome.
Thanks for the patch!