Bug 384037

Hmm actually it does not fix the broken rendering of the taskswitcher (I didn't notice that compositing got disabled while debugging), but I think the rest of the issue is still a valid case.

Hi Sandro,

It looks like you've mixed up the bug report with some attempt at troubleshooting, but without enough detail on either of those to lead us to a fix.

As I understand it, the actual issue is that kwin has "some functionality not working", task switcher in particular.

You think this may be related to Desktop File Parser, I'm guessing based on a review of logs and console output.  But we don't have enough detail here to show whether the warning message you saw is really a kwin bug, or perhaps kwin searching for an old-style kwin-effects as a fallback after properly searching for kwineffects.desktop.

In other words, KWin might be doing the right thing and DesktopFileParser might be doing the right thing, with a packaging error of some sort thrown in.  But it's hard to tell, a lot of the "normal looking" logs we don't have here would help us to eliminate potential problems.

I'm CC'ing the maintainers for both of these in case either have seen this, but I would recommend at the very least to attach the full kwin output logs you have from where you're experiencing issues, and to provide additional detail about what exactly the problems are (including related issues), what parts of KWin are still working, graphics drivers in use, the last working version of kwin and when things stopped working right, etc.  Thanks.

For clarity, I'm not sure at this point what possible consequences the failure to load these service files has. But I don't think it's a packaging issue, since the kwin.spec [1] does not do anything particular to those files, and also since google returns many of results for that error message, originating from a variety of distros.

Again for clarity, the issue for this bug report is simply  whether service file names should be i.e.

kwineffect.desktop

or

kwin-effect.desktop.

In the latter case, the code in the DesktopFileParser::convert should possibly be

QString fileName = service.toLower().replace(QLatin1Char('/'), QLatin1String(""))+QStringLiteral(".desktop");

Sorry for the confusion, I had initially misdiagnosed the results of my debugging session.

[1] https://src.fedoraproject.org/rpms/kwin/blob/master/f/kwin.spec

Michael, does comment #3 provide the requested information? Please set the bug status.

Apologies for the delay, I've been fighting through some hardware issues that made updating Bugzilla infeasible.

I believe this is a kcoreaddons bug after all.

In commit 49bc26a135bf92bcddecabfdd4f3f71f65540104 we added a heuristic to find and load old-style services (where the code was not ported to generate or look for the new JSON plugin format) but this heuristic doesn't find all the .desktop file entries it might need to locate.

In particular, things like "kwin-effect.desktop", which gives error messages in systemsettings5 like "kf5.kcoreaddons.desktopparser: Could not locate service type file kservicetypes5/kwin-effect.desktop, tried ("/home/kde-svn/.local", "/home/kde-svn/kde-5/share", "/usr/share")".  The file kservicetypes5/kwineffect.desktop does exist, however.

I'm not quite sure the best way to fix though.  Presumably we'll want to look for both naming styles.

Created attachment 107947 [details]
Potential fix

I'm attaching what I think is a potential fix.  Seems to work OK in my testing here although I had never really noticed a problem before, so perhaps I'm not the best one to test.

*** Bug 380013 has been marked as a duplicate of this bug. ***

Git commit 4bdc7bb199ecd5120a665600394ac6d69ee1e830 by Michael Pyne.
Committed on 05/10/2017 at 00:53.
Pushed by mpyne into branch 'master'.

desktoptojson: Improve legacy service type detection heuristic.

This commit adds a second-pass heuristic converting requests for named
service types into possible file names for corresponding Desktop Entry
files as used in previous KDE releases.  The current heuristic converts
'/' in the requested service type name to '-'.  If that fails to find a
file, we now also convert '/' to '' (i.e. nothing) and try again before
returning an error.

This fix introduces an autotest regression if you have KDevelop
installed, since the updated code now finds the *real* KDevelop/Plugin
service type desktop entry in a test where it was expecting not to, the
"kdevcppnolanguagesupport no servicetype" test.  To avoid installed
software affecting the tests I rename the service type and verify that
the "no servicetype" and "with [fake] servicetype" tests continue to
pass.
FIXED-IN:5.39

Differential Revision: https://phabricator.kde.org/D8002

M  +1    -1    autotests/data/servicetypes/fake-kdevelopplugin.desktop
M  +3    -3    autotests/desktoptojsontest.cpp
M  +23   -6    src/lib/plugin/desktopfileparser.cpp

https://commits.kde.org/kcoreaddons/4bdc7bb199ecd5120a665600394ac6d69ee1e830

*** Bug 389434 has been marked as a duplicate of this bug. ***