Hello, specifically in this case, how should ksmserver properly launch autostart apps, when they are specified by their .desktop files?
When the autostart launching code was moved from klauncher to ksmserver by [1], it replaced the launching by simply using QProcess, which caused a number of problems such as not parsing the Exec line properly (fixed by [2]), ksmserver discarded all stderr of launched apps instead of them going to ~/.xsession-errors, and launched apps getting killed by SIGPIPE under specific circumstances. I got bitten by these and simply fixed it with [3] by using KRun::runApplication(), as AFAIK that is the proper way to launch something using a .desktop file. Seeing that others had these problems as well (the bugreports mentioned in the commit message for [3]), I backported it after some time. And, after 5.9.5 got out, bug #379254 ([4]) has been reported, about desktop startup taking too long. It turns out that some distros ship broken autostart .desktop files, KRun shows a blocking error dialog (under ksplash) and that blocks the whole startup. To make this even worse, it's not very obvious why the error shows up, and even if it were, kcm_autostart actually completely ignores global autostart files. Now, does somebody know how this should be done properly? QProcess has poor defaults for fire-and-forget launching of apps (bye-bye stderr, hello SIGPIPE). KProcess is better, but there's still a lot of what KRun/klauncher do that would need to be copy&pasted: All the .desktop file parsing and KProcess setting up, kdeinit, KAuthorized, X-KDE-RunOnDiscreteGpu. Not that I know if all of this matters much nowadays, but if it wasn't needed, then why KRun still does it, and one way or another all the manual setup would be lame. I've also looked at KToolInvocation::startServiceByDesktopPath(), which talks to klauncher directly, but there I'm not sure what the status with klauncher is (I mean, if the autostart code hadn't been moved, there wouldn't be any of this), and also while the function is technically not deprecated, its documentation has @deprecated suggesting to use QProcess (ugh) or KRun. So I guess that leaves KRun and just making sure it optionally doesn't show the blocking dialog, such as adding "QString* error = nullptr"? Or does somebody have a better idea? And if not, is it ok to just commit this change to kio repository, or are there nowadays any special rules for library commits now that there are zillion git repos? [1] https://cgit.kde.org/plasma-workspace.git/commit/ksmserver?id=d9883511c92e448b3441d994170fa1d43eea4ff2 [2] https://cgit.kde.org/plasma-workspace.git/commit/ksmserver?id=889be45e893425273d545a73edc42c4bbead446d [3] https://cgit.kde.org/plasma-workspace.git/commit/ksmserver?id=0377d6a992725e0b0b469b87d17343fa3730b829 [4] https://bugs.kde.org/show_bug.cgi?id=379254 -- Lubos Lunak