Bug 169017

One more thing when the file is opened dolphin widow turn entirely grey and stays like that for a few seconds before popping these errors.

Error 1 happens only once. 

I can reproduce the bug even in current trunk. And as
mentioned in bug 157853, getting rid of the
"X-DBUS-StartupType=Multi" line in the kcachegrind.desktop
file fixes the issue. But this is not the real fix.
So marking as duplicate.

*** This bug has been marked as a duplicate of 157853 ***

Just one doubt. Can you tell me why its only happening with kcachegrind. I notice this problem only with this one.

This is definitely a problem around the DBUS communication at startup.
In this regard, KCachegrind just uses standard code from the KDE
library. There is only one (!) line in the whole source code where
DBUS is mentioned explicitly (everything else should be done totally
transparent to the application code in the KDE library): Registering
the new KCachegrind window to DBUS, so that the window could be
controlled from the outside (e.g. triggering menu actions via DBUS).

Yes, it could be that this window registration done simultaneously
with standard DBUS startup registration leads to some kind of
deadlock with the symptoms you see. However, the bug still has to be
in KDE libraries, as this is a valid thing to do.

What about the other applications mentioned in above bug report?

As said, a workaround is to remove the DBUS keyword from kcachegrind.desktop.

For the record, I fixed this the proper way some time ago by adding
X-DBUS-ServiceName=net.sf.kcachegrind
to the desktop file.

Ah yes, I saw the commit, but forgot to close this bug.
Will do now, but I have absolutely no idea why specifying
the DBUS service name fixes the problem.
Thanks!

BTW, when I start dolphin in a KDE3 environment, the
KDE3 kcachegrind opens the file, but dolphin says
"KDEInit could not launch '.../kde3/bin/kcachegrind'".
Should I add a service name to that desktop file (of
the KDE3 version of kcachegrind), too?

True this isn't very much documented. I just created http://techbase.kde.org/Development/Architecture/KDE4/Starting_Other_Programs, please check if the klauncher section answers your question :-)

For dolphin-kde4 making klauncher-kde4 start kcachegrind-kde3, hmm, I assume it's finding the kcachegrind-kde4 desktop file, not the kcachegrind-kde3 desktop file, otherwise it wouldn't assume anything about it registering to dbus... [unless you're using 4.0.x or 4.1.0, before I fixed kservice not to treat the old dcop fields as meaning something about dbus]. I'm not sure how this could be fixed then, it's reading info about kcachegrind-kde4 and then starts kcachegrind-kde3, which behaves differently; this can't work.

Thanks for the description!

I am just not sure I would look
at this page when there is an error when another program is
running mine...
To make sure: the name "net.sf.kcachegrind" in the desktop file
is used both for klauchner waiting for registration, and also
by QDBusConnection::registerObject() to know which service to
register at all? Or does the latter come from another source
(such as KAboutData)?
And a suggestion: If there is no X-DBUS-ServiceName entry,
would it be possible to add a command line argument with a
unique random service name when launching?

I also added pointers to that page from the KToolInvocation api docs, but yeah, not sure how to make this better.

The name in the desktop file tells klauncher what to look for.
The application itself registers using the info in KAboutData. When there's a mismatch between those two things, you get the klauncher error.
An app starting up doesn't really know its own .desktop file [there could be more than one, there could be none at all...], so it can't read it from there.

> add a command line argument with a unique random service name when launching

We could add a --dbusname, I guess. Would work when specified in .desktop files, but the idea of klauncher adding a random name (for multi apps, not for unique apps of course), would break apps and users expectation. Right now the output of qdbus tells you which apps are running, org.kde.konqueror-16092 is easily recognizable, while org.kde.fjwigkaolhw wouldn't be ;)