Bug 247284 - bluez-gnome's autostart .desktop file fails to start under a KDE session
Summary: bluez-gnome's autostart .desktop file fails to start under a KDE session
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: bluez-gnome
Version: 7
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Bastien Nocera
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-07-06 17:20 UTC by Niko Mirthes
Modified: 2007-11-30 22:12 UTC (History)
0 users

(edit)
Clone Of:
(edit)
Last Closed: 2007-08-20 12:20:31 UTC


Attachments (Terms of Use)
Patch allowing bluez-gnome's autostart file to start as expected under a KDE session (325 bytes, patch)
2007-07-06 17:20 UTC, Niko Mirthes
no flags Details | Diff

Description Niko Mirthes 2007-07-06 17:20:18 UTC
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 
session.

How reproducible:
Always.

Steps to Reproduce:
1. Start a KDE session
  
Actual results:
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.

Expected results:
The desktop files in the system-wide autostart directory should start without 
major issues.

Additional info:
The attached patch adds:

StartupNotify=false
X-KDE-autostart-after=panel

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 
autostart directory.

Comment 1 Niko Mirthes 2007-07-06 17:20:18 UTC
Created attachment 158675 [details]
Patch allowing  bluez-gnome's autostart file to start as expected under a KDE session

Comment 2 Bastien Nocera 2007-07-07 00:02:43 UTC
+StartupNotify=false
+X-KDE-autostart-after=panel

Those seem to make some sense. But why would it *fail* to start under KDE
without those?

Comment 3 Niko Mirthes 2007-07-07 01:03:12 UTC
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.


Comment 4 Bastien Nocera 2007-07-07 01:25:07 UTC
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).

Comment 5 Niko Mirthes 2007-07-07 02:09:29 UTC
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.


Comment 6 Bastien Nocera 2007-08-20 12:20:31 UTC
Posted at:
http://thread.gmane.org/gmane.linux.bluez.devel/13354

We'll pick it up in the next version of bluez-gnome.

Thanks for the patch!


Note You need to log in before you can comment on or make changes to this bug.