Version: (using KDE KDE 3.5.7) Installed from: Debian testing/unstable Packages I am the author of Edutainment Knoppix (http://campus.ph.fhnw.ch/ICT/LinuxInDerSchule) and use KDE for that distribution. Because application startup takes quite a while from CD/DVD I tend to add "StartupNotify=true" to some desktop files where appropriate. The strange thing I noticed is that there seems to be a third state for StartupNotify besides "true" and "false" -> "missing". Consider the desktop file for TORCS (http://torcs.sourceforge.net): ------------ [Desktop Entry] Version=1.0 Encoding=UTF-8 Type=Application Name=TORCS GenericName=TORCS Comment=3D racing cars simulator game Comment[es]=Juego de simulación 3D de carrera de autos Icon=torcs.xpm FilePattern=torcs Exec=torcs Terminal=false StartupNotify=false Categories=Application;Game;Simulation;3DGraphics; ------------ "StartupNotify=false" is bad because startup takes so long that the kids think that something is broken and either start TORCS a second time or move on to another application. "StartupNotify=true" is also bad because the jumping mouse cursor does not disappear after startup of TORCS and the kids wait half a minute thinking that something is still loading when in fact it is not. If I remove the StartupNotify line from the desktop file everything works like expected: The mouse cursor is only jumping as long as TORCS is loading. This is the third "undocumented" state I am referring to. Is this a bug or an undocumented feature?
After upgrading to KDE-4.3.2 (on Kubuntu-9.10) and removing the StartupNotify line from the desktop file the startup notification defaults to true. Too bad, this way I can not configure the "everything works like expected" state.
According to the FDO specification[1] : "If true, it is KNOWN that the application will send a "remove" message when started with the DESKTOP_STARTUP_ID environment variable set. If false, it is KNOWN that the application does not work with startup notification at all (does not shown any window, breaks even when using StartupWMClass, etc.). If absent, a reasonable handling is up to implementations (assuming false, using StartupWMClass, etc.). (See the Startup Notification Protocol Specification for more details)." So the observed third state (when StartupNotify is absent) is valid according to the FDO specification. [1] http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
Apparently this is as designed according to the spec, according to Jekyll.