| Summary: | "Plugin does not provide configuration file in expected location" error for any kwin script with configuration GUI | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | ryu.ketsueki |
| Component: | scripts | Assignee: | Alexander Lohnau <alexander.lohnau> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alexander.lohnau, Flupp+bugs.kde.org, jodr666, natalie_clarius |
| Priority: | NOR | ||
| Version: | git master | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/frameworks/kcmutils/commit/c9c58de65c07c8a940cb4c9b91777450698f635c | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: |
Screenshot of the issue in question
metadata-compatibility.fods |
||
It can be both since you are using unstable packages, though more often than not, specially since those are 3rd party scripts, is the scripts that needs updating. For parachute its github states the project is on pause and Kwin recently got a new effect similar to it "overview" which uses the same ctrl+meta+d. (In reply to Tony from comment #1) > It can be both since you are using unstable packages, though more often than > not, specially since those are 3rd party scripts, is the scripts that needs > updating. > > For parachute its github states the project is on pause and Kwin recently > got a new effect similar to it "overview" which uses the same ctrl+meta+d. I understand but I didn't report this because of Parachute. It was the only other script I had installed that I could test. What I originally wanted to use is Force Blur. I don't know any other script that is still on active development and have that same kind of configuration dialog or else I would have tested it. It's because Force Blur is recommended to blur the background of transparent windows, like specific GTK Themes and Firefox with a custom CSS that allows for transparency. But because the same problem happened with the only two scripts I have here with configuration windows, I was wondering if it was a script problem or kwin problem. I'm willing to keep testing here to get more conclusive evidence that it may be the case so if you know any other script worth testing... Same issue with a different KWin script and different distro: https://github.com/nclarius/tile-gaps/issues/6 I'm running it without problems on my up to date Arch, so I don't think the problem is the scripts being outdated. I can reproduce the problem on Arch Linux with KWin 5.24.0. Other KWin script users can too, see, e.g., https://github.com/Flupp/sticky-window-snapping/issues/18. It seems, support for supplying metadata via a desktop file (`metadata.desktop`) is not working anymore. Using JSON format (`metadata.json`) seems to work fine. https://develop.kde.org/docs/extend/plasma/widget/setup/#metadatajson. The videowall KWin script, which is distributed with KWin (`/usr/share/kwin/scripts/videowall`), provides metadata in both formats. However, for KWin scripts installed in the home directory, it seems to work only if exclusively the JSON format is used. I now wonder: • Shall KWin scripts generally transition to using `metadata.json`? • If yes, should it be possible to still provide `metadata.desktop` for backwards compatibility? • Since when/which version is the JSON format supported? If JSON support already exists long enough, backwards compatibility via also providing a `metadata.desktop` might not be necessary. Thanks for figuring out for me what the problem is. The KWin scripting tutorial https://develop.kde.org/docs/extend/plasma/kwin/ doesn't even mention the json format and says to use the .desktop format, and now with 5.24 those don't work anymore for me either, so that documentation should really be updated. I believe this issue can be fixed by putting `X-KDE-ConfigModule=kwin/effects/configs/kcm_kwin4_genericscripted` in metadata.desktop (it's a preferred way to mark configurable scripts anyway), but old configs still need to work. (In reply to Vlad Zahorodnii from comment #6) > I believe this issue can be fixed by putting > `X-KDE-ConfigModule=kwin/effects/configs/kcm_kwin4_genericscripted` in > metadata.desktop (it's a preferred way to mark configurable scripts anyway), > but old configs still need to work. This also appears to solve https://bugs.kde.org/show_bug.cgi?id=411430. Putting `X-KDE-ConfigModule=kwin/effects/configs/kcm_kwin4_genericscripted` in `metadata.desktop` indeed solves the problem for Plasma 5.24.0. However, I then get the “Plugin does not provide configuration file in expected location” error message on Plasma 5.23.5 when clicking the config button. (Regardless if I keep the old `X-KDE-Library=…` or not.) So what is the preferred solution for maximal backwards compatibility? I fear many users/distributions will not update to Plasma 5.24 any time soon. Created attachment 147299 [details]
metadata-compatibility.fods
I checked several Plasma versions to find out which metadata formats work or don’t work for each version.
For `metadata.desktop`, I varied usage of `X-KDE-ConfigModule` and `X-KDE-Library`, and I varied symlinking the desktop file in `~/.local/share/kservices5/`. For `metadata.json` I just used one variant with `X-KDE-ConfigModule` and without symlink.
Depending on the Plasma version, I encountered four different outcomes (details can be found in the attached `metadata-compatibility.fods`):
• Plasma 5.24.2, 5.24.1: all variant work except `metadata.desktop` with `X-KDE-Library` and without symlink.
• Plasma 5.24.0: same as above except `metadata.desktop` with `X-KDE-Library` and with symlink results in the reported error message.
• Plasma 5.23.5, 5.23.4: Only `metadata.desktop` with `X-KDE-Library` and with symlink works. Any version using `X-KDE-ConfigModule` results in the reported error message.
• Plasma 5.23.2, 5.23.1, 5.22.5, 5.20.5, 5.18.5: All variants using `X-KDE-Library` and symlink work. For the `metadata.desktop` using only `X-KDE-ConfigModule` with symlink, clicking the configuration button results in the error message “The module Sticky Window Snapping is not a valid configuration module. The diagnosis is: The desktop file kwin-script-sticky-window-snapping.desktop does not specify a library.”
From that I infer that, for maximal backwards compatibility, we are stuck with the variant `metadata.desktop` with `X-KDE-Library` and with symlink for quite some time when there is no further bugfix release for Plasma 5.23 assuming many distributions currently using Plasma 5.23 won’t switch to a newer version soon. That is unfortunate because this variant requires manual intervention by the user creating the symlink even with the newest Plasma version.
(In reply to Flupp from comment #9) > I checked several Plasma versions to find out which metadata formats work or > don’t work for each version. > > ... > > From that I infer that, for maximal backwards compatibility, we are stuck > with the variant `metadata.desktop` with `X-KDE-Library` and with symlink > for quite some time when there is no further bugfix release for Plasma 5.23 > assuming many distributions currently using Plasma 5.23 won’t switch to a > newer version soon. That is unfortunate because this variant requires manual > intervention by the user creating the symlink even with the newest Plasma > version. Thanks a lot for taking the time to investigate and summarize this! The variant I went with now was to publish the metadata with `X-KDE-ConfigModule`, and instruct users of older Plasma versions to run a sed command replacing that part with `X-KDE-Library` before creating the symlink: > sed -i 's/ConfigModule/Library/g' ~/.local/share/kwin/scripts/floatingtiles/metadata.desktop > mkdir -p ~/.local/share/kservices5/ > ln -sf ~/.local/share/kwin/scripts/floatingtiles/metadata.desktop ~/.local/share/kservices5/floatingtiles.desktop > qdbus org.kde.KWin /KWin reconfigure If they have to manually intervent anyway, might as well add one line more, and that way at least users of an up-to-date system can use the scripts out-of-the-box. But of course it would be preferable if there was a fix for older Plasma versions so it works automatically for them too. A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kcmutils/-/merge_requests/82 This MR should fix it for the deprecated code path. With KCMUtils 5.91 and KWin 5.24, https://invent.kde.org/frameworks/kcmutils/-/commit/60ac2bf394c9cd8a142698332ffdbee55a61e705 will fix the issue. Maybe that should be backported for distros that only ship Frameworks 5.91, but Plasma 5.24. (In reply to Alexander Lohnau from comment #12) > This MR should fix it for the deprecated code path. That would be great! Could you please clarify which of the variants Flupp listed systems receiving this update will work with? Did I understand it correctly that this fix makes KWin versions <5.24 behave like 5.24, in that that the X-KDE-ConfigModule variant without symlinking works? Are there any differences in compatibility for metadata.desktop vs. metadata.json? >Could you please clarify which of the variants Flupp listed systems receiving this update will work with?
X-KDE-ConfigModule with KCMUtils >= 5.89 and KWin 5.23. For KWin 5.24 a fix has already landed with frameworks 5.91.
Git commit c9c58de65c07c8a940cb4c9b91777450698f635c by Alexander Lohnau. Committed on 14/03/2022 at 11:28. Pushed by alex into branch 'master'. Fix KPluginSelector KCMs missing their metadata on plugin loading For the KWin KCMs we need the full metadata, because we read the plugin keyword. Without the X-KDE-ConfigModule key, plugins used to create a symlink in the kservices5 folder to their metadata, which then goes through the legacy code path we would read all the metadata. This includes the plugin keyword. When consumers would this key, but have an old KWin version which used the KPluginSelector class and a kcmutils version which reads X-KDE-ConfigModule, but does not include this bugfix, the plugin keyword will be empty and thus the config files can not be located. This makes it hard to fix the loading on kcmutils < 5.91, but keeping the code working with KWin < 5.24. To test this, you should check out KWin 5.23 and kcmutils master. Fox example https://github.com/nclarius/tile-gaps/ will then fail to load it's config. With this change included, it should load properly. M +3 -4 src/kpluginselector.cpp https://invent.kde.org/frameworks/kcmutils/commit/c9c58de65c07c8a940cb4c9b91777450698f635c |
Created attachment 142861 [details] Screenshot of the issue in question SUMMARY The title is an error that appears with every script I have here with me, namely Force Blur and Parachute. Those plugins have configuration dialogs that were symlinked to the kservices5 folder as instructed and worked perfectly in previous verions of plasma. What I would like to know is if this is regarding a broken feature or the scripts really need to be reworked to use the new "save to configuration file" location and if so, how it could be done. STEPS TO REPRODUCE 1. Use any KWin Script that has a configuration dialog with more options 2. Open said configuration dialog through KWin Scripts list OBSERVED RESULT Pop up return with the message in the title as error EXPECTED RESULT The configuration dialog to open as intended and allow to configure the script SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20211019 KDE Plasma Version: 5.23.80 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.2 Kernel Version: 5.14.11-2-default (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i3-7020U CPU @ 2.30GHz Memory: 11.5 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 620 ADDITIONAL INFORMATION Packages are coming from KDE Unstable Repos available for openSUSE Krypton. I am not sure on which commit of kwin I am exactly.