This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 247284 - bluez-gnome's autostart .desktop file fails to start under a KDE session
bluez-gnome's autostart .desktop file fails to start under a KDE session
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: bluez-gnome (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Bastien Nocera
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-06 13:20 EDT by Niko Mirthes
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-20 08:20:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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 13:20 EDT, Niko Mirthes
no flags Details | Diff

  None (edit)
Description Niko Mirthes 2007-07-06 13:20:18 EDT
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 13:20:18 EDT
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-06 20:02:43 EDT
+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-06 21:03:12 EDT
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-06 21:25:07 EDT
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-06 22:09:29 EDT
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 08:20:31 EDT
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.