Executing system settings from kickoff does not open system settings as it seems to pick up KDE4 system settings - after launching it, it prints: Kickoff::UrlItemLauncher::Private::openUrl: Opening item with URL "/usr/share/applications/kde4/systemsettings.desktop" This might be related to a co-installability of system settings, however opening it from Kicker works just fine.
the fact that one or the other may get picked looks a lot like a local installation issue. But, to shed some light, the key difference between kicker and kickoff, is that to lauch something, kickoff does KRun("/path/name") while kicker does KRun(KService *)
I wonder if those two should not use the same mechanism, does anyone know what the advantage of one over the other would be? (Apart from this bugreport.)
I'm not sure about the differences either, but do note that KService maintains two conceptual abstractions over .desktop files, menuId (strict) and storageId (lenient) along with the respective find*() calls ... it felt more reliable to me to rely on those mechanisms than to keep .desktop file system paths around. I think the storageId stuff in KService might also have some special handling for the 'kde4-' prefixes in ids, and I also recall seeing creaky old code in Kickoff that somehow tried to arbitrate between KDE 3 and 4 apps that might become involved in some fashion somewhere.
After talking to mck182, I can confirm mck182 has a fcked up env and it's probably his fault :) I can't reproduce this, and the ISO works fine too.
> I can confirm mck182 has a fcked up env and it's probably his fault :) Now how can you confirm that? :P My env as such is rather correct otherwise nothing else would work (what's wrong is my xsession start up file but that should not have any effect on this). This might as well be a bug in sycoca or KService or whatever puts system settings in the menu. And ISO works fine because it surely has no KDE4 System Settings :P Nevertheless, both launchers should probably use the same mechanism to start things...