Note: I'm not sure whether this is a bug in kf5-kcoreaddons or kwin DesktopFileParser::convert has the following code: // some .desktop files still use the legacy ServiceTypes= key QString fileName = service.toLower().replace(QLatin1Char('/'), QLatin1Char('-'))+QStringLiteral(".desktop"); However, kwin (and others, judging from ls /usr/share/kservicetypes5/), don't have a dash in their service desktop filenames, i.e.: kwineffect.desktop kwinscript.desktop kwinwindowswitcher.desktop etc Currently, DesktopFileParser::convert makes kwin look for i.e. kwin-windowswitche.desktop and so on, which results in errors like kf5.kcoreaddons.desktopparser: Could not locate service type file kservicetypes5/kwin-effect.desktop, tried ("/home/sandro/.local/share", "/usr/share/kde-settings/kde-profile/default/share", "/usr/local/share", "/usr/share") and some functionality not working (in this case, the task switcher). I suppose either DesktopFileParser::convert generates an incorrect filename, or kwin names its service files incorrectly (see https://smani.fedorapeople.org/taskswitcher.jpg). Using - kf5-kcoreaddons-5.37.0-1.fc28.x86_64 - kwin-5.10.5-1.fc28.x86_64 on Fedora rawhide.
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. ***