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>?
cc'ing Elijah, who probably knows this spec better than me. I'd say this is a bug in KDE. KDE shouldn't set this environment variable if the application is not started from a desktop entry with StartupNotify=true Also, question for Elijah: how comes that http://standards.freedesktop.org/startup-notification-spec/startup-notification-0.1.txt contains "Changes since 0.1"? :-)
(In reply to comment #1) > I'd say this is a bug in KDE. KDE shouldn't set this environment variable if > the application is not started from a desktop entry with StartupNotify=true Maybe it should not, and my desktop entry explicitely has StartupNotify=false. On the other hand the spec doesn't clearly say so in my opinion, so as far as I can tell KDE is following the spec at least literally. Relying on the StartupNotify setting would require the desktop manager or its user to know about the startup support capabilities of at least most applications, otherwise you'd see this feature mostly disabled to be on the safe side. If the spec could be improved so that the application itself could tell whether it supports that protocol or not, that would be a lot better imho.
Related KDE bug http://bugs.kde.org/show_bug.cgi?id=108618 resolved WONTFIX.
(In reply to comment #2) > (In reply to comment #1) > > I'd say this is a bug in KDE. KDE shouldn't set this environment variable if > > the application is not started from a desktop entry with StartupNotify=true > > Maybe it should not, and my desktop entry explicitely has StartupNotify=false. If you have StartupNotify=false and KDE is using startup notification, then, well, that's really a KDE bug. > On the other hand the spec doesn't clearly say so in my opinion, so as far as I > can tell KDE is following the spec at least literally. While the spec text could be improved, it seems quite clear to me how this part works. Do you have any suggestion to improve this part of the spec? > Relying on the StartupNotify setting would require the desktop manager or its > user to know about the startup support capabilities of at least most > applications, otherwise you'd see this feature mostly disabled to be on the > safe side. If the spec could be improved so that the application itself could > tell whether it supports that protocol or not, that would be a lot better imho. But the desktrop entry files are provided by the applications, so this should be enough in most cases. If the user creates a desktop entry file, then this setting should be unset and the spec clearly states: "If absent, a reasonable handling is up to implementations (assuming false, using StartupWMClass, etc.).".
> If you have StartupNotify=false and KDE is using startup notification, then, well, that's really a KDE bug. It's not. The spec says what StartupNotify=false says about the application, not about the launcher, it does not say anywhere that the launcher must not use it in such case. KDE still uses it internally. As for the PID idea, I doubt that it's certainly feasible. In some cases, when the startup ID is created, it is not even known what will be started, let alone its PID. Given that this problem concerns only relatively corner cases and the fixes (unsetenv("DESKTOP_STARTUP_ID")), workarounds (wrapper script doing the same) or merely switching off an optional feature are obvious, I don't see it worth much bothering. I can probably try adding ignoring of old ids if the fix would be simple enough. (Oh, and the spec contains changes since 0.1 because it's not 0.1 but something like post-0.1.)
(In reply to comment #4) > While the spec text could be improved, it seems quite clear to me how this > part works. Do you have any suggestion to improve this part of the spec? The text only says that the wm should not hope for a "remove" message, not that it should not set DESKTOP_STARTUP_ID. You could append DESKTOP_STARTUP_ID must not be set unless StartupNotify=true to the description of the StartupNotify desktop entry if this really is what you want. From what I read, at least KDE would not want that part of the spec. > But the desktrop entry files are provided by the applications, so this should > be enough in most cases. Hmmm... I created most of mine myself, I think, but probably you are right and in most cases, especially for inexperienced users, this could work. (In reply to comment #5) > As for the PID idea, I doubt that it's certainly feasible. In some cases, when > the startup ID is created, it is not even known what will be started, let > alone its PID. How come? The request to start something is passed along a bit inside the launcher, but as soon as it leaves the launcher, some other application would get started, and the ID could be generated or alternatively rewritten at that time. Or do you need the final ID before you reach that point? Would the PPID work any better? Checking its direct parent should work reasonably well, and the PID of the launcher should be known at the time the launch is initiated. > Given that this problem concerns only relatively corner cases and the fixes > (unsetenv("DESKTOP_STARTUP_ID")), workarounds (wrapper script doing the same) > or merely switching off an optional feature are obvious, I don't see it worth > much bothering. The later you try to fix a problematic spec, the more trouble it will give you. This is an issue that should be solved one day, and the longer you wait, the more headache it will cause you. Plus the more people will implement the current spec just to rewrite it when you update it. Better to update the spec soon. > I can probably try adding ignoring of old ids if the fix would > be simple enough. How would you detect them? If there was an obvious way, then it should maybe described in the spec. Otherwise it feels a bit like a hack, and maybe we should try a bit harder to find a viable solution that gives us a clean specification ensuring maximum interoperability.
(In reply to comment #5) > > If you have StartupNotify=false and KDE is using startup notification, then, > well, that's really a KDE bug. > > It's not. The spec says what StartupNotify=false says about the application, > not about the launcher, it does not say anywhere that the launcher must not use > it in such case. KDE still uses it internally. Ah, right. But is there any reason to use it if StartupNotify=false? I mean, you know it doesn't work in this case, so why use it? Would you agree to put this in the spec?
> But is there any reason to use it if StartupNotify=false? I mean, you know it doesn't work in this case, so why use it? I know it doesn't work perfectly, which is different from not working at all. It can still be useful even without providing the usual visual feedback. > Would you agree to put this in the spec? Probably not, merely on the base that it is an implementation detail that does not belong to the spec. That said, I could try to fix the problem this way, but I don't see any reason why it should be outright forbidden. As far as I am concerned, this whole issue is a KDE problem (that may or may not be fixed) and does not belong here.
(In reply to comment #8) > Probably not, merely on the base that it is an implementation detail that does > not belong to the spec. > As far as I am concerned, this whole issue is a KDE problem (that may or may > not be fixed) and does not belong here. I disagree in both cases. Right now KDE follows the spec (because setting the var is not outright forbidden), the terminal apps follow it (by removing the variable immediately after they have read it - which is never), and the apps started from terminal follow it (by sending the appropriate message) and still there are problems. Clarifying the situation in the spec and clearly describing responsibilities would help avoid such problems. Otherwise this is maybe a suggested procedure, but nothing I'd call a specification. You could call this whole startup notification scheme an implementation detail and forget about the spec, but as soon as you want it to work across different implementations, you have to define what you require from applications and make sure these requirements are enough to make it work. If you say this should be fixed in KDE alone, then maybe the spec should require any window manager to take care of the issue in a similar way.
I agree with Martin that it makes sense to put in the spec an interpretation to help with implementation. It's quite usual to do this in specs...
I have no problem with adding interpretation where it makes sense - I disagree with adding this specific detail just because of apps that don't follow the spec anyway. I can very well fix the KDE problem in a different way.
Sorry for the noise, reassigning to new (since 2 years) maintainers (Ryan & David).
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xdg/desktop-file-utils/issues/34.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.