Bug 335877 - Kickoff picks up KDE4 system settings
Summary: Kickoff picks up KDE4 system settings
Status: RESOLVED NOT A BUG
Alias: None
Product: plasmashell
Classification: Plasma
Component: Application Launcher (Kickoff) (show other bugs)
Version: master
Platform: unspecified Linux
: NOR normal
Target Milestone: 1.0
Assignee: Sebastian Kügler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-06 12:26 UTC by Martin Klapetek
Modified: 2014-07-09 21:07 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Klapetek 2014-06-06 12:26:57 UTC
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.
Comment 1 Marco Martin 2014-06-09 10:57:22 UTC
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 *)
Comment 2 Sebastian Kügler 2014-06-10 11:20:44 UTC
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.)
Comment 3 Eike Hein 2014-06-10 11:53:47 UTC
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.
Comment 4 David Edmundson 2014-07-09 19:56:31 UTC
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.
Comment 5 Martin Klapetek 2014-07-09 21:07:15 UTC
> 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...