https://bugs.kde.org/show_bug.cgi?id=456618
--- Comment #3 from burak.yncr.4...@gmail.com --- 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. -- You are receiving this mail because: You are watching all bug changes.
