Startup notification handles intermediate apps badly wrt. DESKTOP_STARTUP_ID
Submitted by Martin von Gagern
Assigned to Allison Lortie @desrt
Description
The startup notification states that "It is suggested to unset this environment variable (DESKTOP_STARTUP_ID) in the launchee as soon as it's read, to avoid possible reuse by some process started later by launchee."
A launchee that doesn't implement this specification will cause other applications launched from it to break if they do implement it. In the situation at hand, I have a terminal application (urxvt) that doesn't handle DESKTOP_STARTUP_ID in any way special. KDE sets the variable, and applications started from the terminal will receive and act upon it, causing their windows to be placed in the background according to the timestamp from the terminal application startup.
The specification should probably be more precise and require the launchee to only pass this variable to child applications started as a direct consequence of the parents startup. But this would still require every possible intermediate app to implement the spec, which is not very realistic.
Maybe the spec could furthermore require some part of the unique identifier to be the PID of the started child process. This value is known after the fork and prior to the execv call, and can be placed in the environment variable. A launchee could then check if it detects such a pid, and if it does and that pid does not match its own pid, it should ignore the DESKTOP_STARTUP_ID.
If most launchers were updated to include that pid in the unique identifier, and most launchees to recognize and check it, then most problems could be avoided without breaking the current level of interoperability with applications that haven't been upgraded yet.
Special considerations should perhaps be taken for startup scripts and other intermediate processes that are part of an application startup. In cases where the pid is really different from the one of the final started application, the script would have to know about it and adjust the value accordingly. While this would indeed require some work, it is ceratinly feasible. I'd expect most startup scripts to exec the final application, thus resulting in the same pid.
How about a format like <uniqe>_PID<launcheepid>_TIME<timestamp>?