Confirmed with "Personal Folder" but I can't reproduce it anywhere else.

Also confirmed with "Find Files/Folders" and "Help", both of which are in the top-level menu. Tracing it out, it appears to be an issue with KToolInvocation::startServiceByDesktopPath(). It is only called once with the desktop file that the menu iterm corresponds to but the application is started twice.

I assume the bug is somewhere located at MenuLauncherApplet::actionTriggered() and the way the activation is redirected to the model. Unfortunately I have no clue how to put items into the top-level and here there are no "Personal Items", "System Settings", "Help" or "Find Files" displayed at all. Not at the top-level nor somewhere else.

But if I remove in the $INSTALLDIR/share/applications/kde4/systemsettings.desktop the line
Categories=Qt;KDE;Settings;
it's at least displayed at the "Others" category but still not at the top-level.

Probably does anybody have a hint here how to manipulate a desktop-file to have it in the top-level? Would make testing it much easier :)

p.s. digging through techbase doesn't helped either to understand how that works.

Is simply :)

Replace the Categories=.*  in that desktop file with :

Categories=Qt;KDE;Core;

Thanks Gabriel :)

Seems something on my setup doesn't like that at all. Every desktop-file which has the core-category isn't displayed within any of the launchers. Even hard-coding an item doesn't seem to work for me :-/

Anyway, to provide some more input in the hope somebody got it fixed before I was able to find a way to reproduce it;

Within the file http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/applets/kickoff/simpleapplet/simpleapplet.cpp?view=markup the method
MenuLauncherApplet::actionTriggered(QAction *action)
does handle the "menuitem got executed" event. For that it just tries to redirect the call to the proper view (the kmenu may display multiple MenuView instances where we use e.g. one view for the ApplicationModel and another view for the FavoritesModel - all of them got them merged together into the single KMenu Launcher). The MenuView itself is located at http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/applets/kickoff/simpleapplet/menuview.cpp?view=markup and there we call the MenuView::actionTriggered method.
Now I can imagine that the problem is, that within the constructor of that class we do connect(this,SIGNAL(triggered(QAction*)),this,SLOT(actionTriggered(QAction*)));

Without testing all that, I could imagine that following patch fixes the problem. But I don't know if it really does nor am I able to check if it introduces any sideeffects :-/

Index: simpleapplet/menuview.cpp
===================================================================
--- simpleapplet/menuview.cpp   (revision 755671)
+++ simpleapplet/menuview.cpp   (working copy)
@@ -75,7 +75,7 @@
     : KMenu(parent)
     , d(new Private(this))
 {
-    connect(this,SIGNAL(triggered(QAction*)),this,SLOT(actionTriggered(QAction*)));
+    //connect(this,SIGNAL(triggered(QAction*)),this,SLOT(actionTriggered(QAction*)));
 }
 MenuView::~MenuView()
 {

More next days once I got my local prob sorted out.

I just tested your patch, Sebastian, and it fixed the problems for me (both Dolphin starting twice and the other applications appearing twice). So far I didn't notice that anything else was broken, but I did only a very brief testing.

Yep, works here too.

I don't understand why my debugging showed that KToolInvocation was only being called once, why commenting it out caused no instances to be executed or why apps that aren't single-instance such as Konsole didn't open multiple times... But being fixed is enough for me. :)

fix got committed with r757491 in trunk and r757497 in 4.0 branch, so should be part of 4.0.1