How to launch .desktop files properly?
l.lunak at centrum.cz
Wed May 3 12:02:13 BST 2017
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
, it replaced the launching by simply using QProcess, which caused a
number of problems such as not parsing the Exec line properly (fixed by ),
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  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 ), I backported
it after some time. And, after 5.9.5 got out, bug #379254 () 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?
More information about the kde-core-devel