Version: (using KDE KDE 3.3.2) Installed from: Debian testing/unstable Packages OS: Linux If you try to run a program located in /usr/games (such as kpat or most other kdegames), by launching them from the "Run Command" dialog, then the program runs, but the Run dialog doesn't disappear as it does normally. Rather, it stays, and then when the game is closed, you get a pop-up saying "KDEInit could not launch '/usr/games/kpat'" (or whatever the program), and only after you click OK does the Run dialog vanish. The problem also occurs when you drag the relevant Kmenu entry to the desktop, and create a link. Running the game from this desktop link works, but again, when the program is closed, a pop-up appears, "KDEInit could not..." It seems that though /usr/games is now part of the default path, something somewhere needs an update to fully take this into account. This bug was based on the verified information in Debian bug reports #270592 and #290323. Cheers, Christopher Martin
You tend to get errors like this when the application has a .desktop file with an incorrect X-DCOP-ServiceType line. However that shouldn't be an issue when you enter the application name manually in the Run Dialog. Do you enter "/usr/games/kpat", or do you only enter "kpat" ?
> Do you enter "/usr/games/kpat", or do you only enter "kpat" ? 'kpat'. Entering '/usr/games/kpat' in the Alt-F2 prompt gets it right (i.e., dialog disappears). [Tried with katomic here.]
That seems to the case here as well. FYI, kpat.desktop contains: "X-DCOP-ServiceType=Multi"
X-DCOP-ServiceType=Multi is correct for KDE's kpat binary, so is /usr/games/kpat the original binary or is it a script of some sort?
/usr/games/kpat is a binary, not a script. The Exec line in kpat.desktop is: Exec=/usr/games/kpat %i %m -caption "%c" Could it be that specifying the full path is causing the confusion? Changing it to Exec=kpat does seem to solve the problem, but whether KDE should behave as it does when given a full path, I can't say.
FYI, the full path in the Exec line is an old distro-specific change. Still, KDE should cope when the full path is provided.
Yes, the full path is causing the confusion. Fixed now. This is what is happening: When KDE starts a application it looks at the "X-DCOP-ServiceType" entry. If it says "Multi" or "Unique" it will wait till the application has registered itself with DCOP to ensure that it is properly and fully started. In particular it will wait for an application to register itself using the name specified in "X-DCOP-ServiceName". If that entry is missing (it usually is) it will use the first argument of the Exec line. So for "Exec=kpat" that goes ok, because kpat registers itself with DCOP as "kpat", but with "Exec=/usr/games/kpat" things go wrong, because now KDE will wait for kpat to register itself as "/usr/games/kpat", which never happens. Patch in next comment.
CVS commit by waba: Strip directory when determining DCOP name from Exec line. BUG: 97087 M +4 -0 klauncher.cpp 1.103 --- kdelibs/kinit/klauncher.cpp #1.102:1.103 @@ -997,5 +997,9 @@ KLauncher::start_service(KService::Ptr s request->dcop_name = v.toString().utf8(); if (request->dcop_name.isEmpty()) + { request->dcop_name = request->name; + // Strip directory + request->dcop_name = request->dcop_name.mid(request->dcop_name.findRev('/')+1); + } }
> Patch in next comment. Thanks!
*** Bug 96381 has been marked as a duplicate of this bug. ***
*** Bug 96283 has been marked as a duplicate of this bug. ***
*** Bug 100139 has been marked as a duplicate of this bug. ***
*** Bug 89812 has been marked as a duplicate of this bug. ***
*** Bug 76519 has been marked as a duplicate of this bug. ***
*** Bug 101073 has been marked as a duplicate of this bug. ***