Reposting from my own post on Reddit. I don't know exactly where to put it so putting it in "kde" general issues. App Launcher search/discoverability problem (settings groups) Settings "groups" in 5.21 are not searchable in KRunninger/Appliation Launcher. Just trying out KDE Neon to see the new 5.21 update. Coming from Linux Mint (Cinnamon and XFCE) mostly. Well, also almost 20 years of Mac OS X / macOS. From my perspective there is a major, and I mean MAJOR oversight that I would like to point out, in terms of helping users find settings. It's nice that the settings app has apparently been given significantly more intuitive organization by grouping related settings together, such as everything related to the KDE look grouped under "Appearance". That's something to be proud of. However, do a little experiment with me. Try to search for "appearance" in the new Application Launcher in 5.21. There are nine different modules under the "Appearance" group inside the settings app. But only three things come up in the launcher, and only because they happen to have the word "appearance" in their descriptions, not because any of them are named "Appearance". And there is nothing that is actually called "Appearance". On XFCE, for instance, if you search in the main menu or a launcher like Albert (Spotlight clone), you will find the app called "Appearance" which is responsible for much of the XFCE look. No doubt it shows up so easily because it is an application with a desktop file, or whatever, and the settings groups in the new settings app in KDE 5.21 are just... "groups" of some kind, internal to the application, which the launcher apparently can't see. So I'm sure there is some valid technical reason that the group names in the settings app are not searchable by the App Launcher. But I think this is a huge mistake that should be fixed. The user should be able to type "appear" and already see a primary item called "Appearance" that will take that user into the settings app and open the Appearance group. Same holds true for the other groups in the settings app, I'm just using the Appearance group as an example. There are four items under "Applications" in the settings. Type "applications" into the App Launcher and you get nothing relevant. I end up with Chromium as the highlighted entry, and a few lines above that is the settings module that happens to be called "Default Applications". In XFCE there is an application called "Window Manager". Here in KDE 5.21 there is a settings group called "Window Management", with four modules inside. Search for it. If you type it out verbatim nothing relevant is left showing in the launcher. How about the "Startup and Shutdown" group of settings? Only two of the five modules in that group will even appear when typing "startup" in the launcher. "Workspace Behavior" groups seven different modules together. Only one will show up if you search for "workspace". I hope I'm not the only one here who thinks this is a situation that could be drastically improved pretty easily. Just find a way to make the new settings "groups" searchable items that launch the settings app and enter that group. At the very least each of the settings modules should somehow be made to come up in the launcher when you type in the name of the group. Like, just stick the settings group title in the description somehow. At the beginning, "Workspace Behavior: Touch Screen". Or at the end, "Touch Screen (Workspace Behavior)". In fact that should be done in addition to making the main groups show up as their own item in the launcher. And it shouldn't be some kind of hack that only works in the KDE Application Launcher. It needs to be a solution that would also work with other launchers like Albert. Example: Make a bunch of desktop files named after the settings groups, each of which just launches the main settings app with an add-on command option that opens that specific group of settings.
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