Bug 433566

So basically KCM search results should be included in searches for words in their parent group's name. Seems reasonable. Since that information is in their desktop files, it's parse-able and could be added.

In the future, an essay is not necessary. :)

(In reply to Nate Graham from comment #1)
> So basically KCM search results should be included in searches for words in
> their parent group's name. Seems reasonable. Since that information is in
> their desktop files, it's parse-able and could be added.
> 
> In the future, an essay is not necessary. :)

Thanks for the rename of the title, I'm sure the terms are far more understandable to those who might be capable of implementing a fix. 

Like I said, I'm coming from outside KDE, so I had to be a bit wordy to make sure I was understood. Part of that it simply not knowing what terms to use to be more concise, and not knowing how the software works in the background. 

I hope the solution will also allow launchers like Albert to "see" all the related settings modules when searching for the related group name. Sounds like that should be partially possible.

Depends on how searching is implemented in Albert. It might need to learn how to do this as well as KRunner.

A cruder caveman fix could be to add the KCM's parent cagetory name to the KCM's keyword list, for every KCM that's in a cagetory. This would fix the issue automatically for KRunner, Albert, and System Settings. However these keywords would need to be manually updated every time a KCM got moved, which I can guarantee would get missed, and then the search results would be wrong. So it's probably better to go for the programmatic approach of teaching these search tools how to find out for themselves what a KCM's parent category is, so that it can be used as a search term.

(In reply to Nate Graham from comment #3)
> Depends on how searching is implemented in Albert. It might need to learn
> how to do this as well as KRunner.
> 
> A cruder caveman fix could be to add the KCM's parent cagetory name to the
> KCM's keyword list, for every KCM that's in a cagetory. This would fix the
> issue automatically for KRunner, Albert, and System Settings. However these
> keywords would need to be manually updated every time a KCM got moved, which
> I can guarantee would get missed, and then the search results would be
> wrong. So it's probably better to go for the programmatic approach of
> teaching these search tools how to find out for themselves what a KCM's
> parent category is, so that it can be used as a search term.

It's my limited understanding that launchers like Albert, just like the typical application menus built into other DEs like XFCE/MATE/Cinnamon/etc., finds "applications" by monitoring the appropriate folders for standard .desktop files. I downloaded balenaEtcher as an AppImage file and was forced to create a .desktop file in ~/.local/share/applications in order to get it to show up in the KDE Application Launcher and Albert. Of course that file would need to be updated if I ever moved the balenaEtcher AppImage file. 

I confirmed that Albert can actually only see the main System Settings application, it cannot see any of the KCM settings modules as applications. 

The likelihood that any of the third-party launchers will be reprogrammed to learn the "KDE way" of searching for these modules is highly improbable. The idea of adding the group name to the KCM keywords will only fix this issue for anything using KRunner to search. But at least that would be an improvement, and most KDE users no doubt only care about searching in KRunner or the KDE Application Launcher.

I think this is a good idea.

How would you like the results to be presented? Like when you are searching for "Apperance" do you want to be able to launch the category in systemsettings or just list all the KCMs of that category and launch them as one would do now?

(In reply to Alexander Lohnau from comment #5)
> I think this is a good idea.
> 
> How would you like the results to be presented? Like when you are searching
> for "Apperance" do you want to be able to launch the category in
> systemsettings or just list all the KCMs of that category and launch them as
> one would do now?

I don’t know if this was meant for me, but what I would like to see is both the groups and the individual modules being searchable. The groups exist to help organize the Settings apps. It would make sense to me that searching for “Appearance” and activating it would take me to the same place as opening the Settings app and clicking the Appearance group header. Users can subsequently learn to search for a more specific module in the future if they want to.

> It would make sense to me that searching for “Appearance” and activating it would take me to the same place as opening the Settings app and clicking the Appearance group header.

That should be doable, currently I am working on porting the deprecated loading mechanism for the systemsettings categories. Implementing the feature has to wait for that (https://invent.kde.org/plasma/systemsettings/-/merge_requests/70).

I am also thinking about splitting up the Sysetmsettings/Application plugin. Visually they have different categories already, but they still powered by the same plugin. Also the query mechanism will be deprecated, using separate plugins will make porting that far easier. (See https://phabricator.kde.org/T14557)

I plan to work on this targeting Plasma 5.24

The "Global Theme" KCM currently matches using the keywords and shows up as one would expect