SUMMARY When using the main search box of system settings, typing the name of a desktop effect sometimes leads to the desktop effects applet, while sometimes it doesn't. For example, searching for "Wobbly Windows" takes you to the applet, "Magic Lamp" takes you to the applet, however "Squash" doesn't even though magic lamp does. Typing the name of a third party desktop effect never leads to the applet. The reason this happens is probably because there isn't a dynamic list of desktop effects. All the keywords for KWin effects kcm are hard coded in the KWin sources, specifically the following file: https://invent.kde.org/plasma/kwin/-/blob/master/src/kcmkwin/kwineffects/metadata.json A possible solution is to dynamcally generate a list of installed effects, by querying /usr/share/kwin/effects and /usr/share/kwin/desktop-effects, as well as their ~/.local/share counterparts, and use that list plus the other defined keywords in Systemsettingsrunner::setupMatch function. STEPS TO REPRODUCE 1. Search for a desktop effect that is not in the KCM's keyword list OBSERVED RESULT 1. The user is not directed to kwin-effects kcm applet. EXPECTED RESULT 1. The user should be directed to kwin-effects kcm applet. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Operating System: Arch Linux KDE Plasma Version: 5.25.2 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 Kernel Version: 5.18.10-arch1-1 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-3230M CPU @ 2.60GHz Memory: 7.7 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 4000 Manufacturer: Micro-Star International Co., Ltd. Product Name: GE60 0NC\0ND System Version: REV:1.0 ADDITIONAL INFORMATION Link to the KWin effects kcm source code: https://invent.kde.org/plasma/kwin/-/blob/master/src/kcmkwin/kwineffects/ Link to the KWin effects kcm metadata file: https://invent.kde.org/plasma/kwin/-/blob/master/src/kcmkwin/kwineffects/metadata.json Link to systemsettingsrunner.cpp: https://invent.kde.org/plasma/systemsettings/-/blob/master/runner/systemsettingsrunner.cpp
Yes, that's a correct understanding of the problem and a potential solution. Would you like to try implementing it?
(In reply to Nate Graham from comment #1) > Yes, that's a correct understanding of the problem and a potential solution. > Would you like to try implementing it? Thanks for confirming. I will give it a try.
I revisited this issue after almost 3 years as I this showed up in my email when the title changed. As such, I wanted to give another try at the implementation. However, the solution I found involves adding another dependency (KPackage) to SystemsettingsRunner, and I thought it would be inappropriate to introduce such change without bringing it up here first. Here's the idea: > A possible solution is to dynamcally generate a list of installed effects, by querying /usr/share/kwin/effects and /usr/share/kwin/desktop-effects, as well as their ~/.local/share counterparts, and use that list plus the other defined keywords in Systemsettingsrunner::setupMatch function. This is still part of the solution. However, it would be cleaner to do this using KPackage/PackageLoader like it is done in the KCM itself (https://invent.kde.org/plasma/kwin/-/blob/master/src/kcms/common/effectsmodel.cpp) There are 3 methods to get builtin effects, JS effects and plugin effects respectively. When all 3 are called, the full set of effects are retrieved. We could utilize the same mechanism in SystemsettingsRunner, particularly by calling this logic inside the constructor (should be a separate method to keep the code clean), finding the KWin Effects KCM in the return value of `findKCMsMetaData()` and explicitly adding the effect names into its keywords. In fact, we don't even need to do all the stuff effectsmodel does, we only need to get the effect name - that's it. In the `SystemsettingsRunner::match` method, the keywords are split by commas, which indicates that the metadata object stores the keywords as a comma separated strings and does not parse it on the fly. For this reason, we could join the effect names by commas and concatenate with the `X-KDE-Keywords` value in KCM metadata, which leaves the match method code and logic unchanged. This is a much cleaner implementation than the one I thought of 3 years ago as the method I described back then would query the effects on every keystroke, which would be unacceptable (it would parse 30 JSON files in every keystroke). Since my new proposal involves a single fetch in the constructor, it will be ran just once through the application's lifecycle, making it cost-efficient. I have kde-builder set up and running, so if we are OK with progressing further, we absolutely can. In fact, if we could do even consider to do the same keyword fetching for themes, KWin scripts, window decorations etc. if you see fit, because as far as my understanding goes, the logic stays the same.
This seems like a sensible plan to me. I'd say go ahead and submit it as a merge request, and we'll see how it goes!
A possibly relevant merge request was started @ https://invent.kde.org/plasma/systemsettings/-/merge_requests/368