https://bugs.kde.org/show_bug.cgi?id=433566
--- Comment #4 from Kris Finkenbinder <redb...@redbearnet.com> --- (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. -- You are receiving this mail because: You are watching all bug changes.
