With the default configuration (scan_start_menu and scan_env_path enabled) all file-types located at the Desktop get listed and not only executables (or links to executables).
I think that this behaviour is not consistent with the one for directories listed in PATH or extra_paths.
(Personally, I didn't expect Desktop to get scanned at all ^_^)
Steps for reproducing
Create a .txt-file at the Desktop
Use the default-configuration for Apps
Search directly for the in step 1 created file
Expected behaviour: File should not be listed. Actual behaviour: File gets listed.
Suggestion for fix/change
I think the inital problem is, that the items located at the start menu are not executable files, but windows-shortcuts. Nevertheless, we know that all these will link to executables so we can ignore scan_env_path in _catalog_startmenu.
But Desktop can contain different file-types. Therefore in this special case we should look for executables and for shortcuts, but only which one are linking to executables!
(Another way could be just not to look inside Desktop)
The text was updated successfully, but these errors were encountered:
The most obvious change that would blend best to the existing features would be to add a scan_desktop setting (boolean; enabled by default). That would not perfectly fit your wishes since the underlying request behind your comment is to have some kind of file filtering feature. At least, that's what your request implies technically. But as things are currently, the Apps package doesn't allow such thing and the KISS principle prevails here.
An ideal solution is to roll up an extra package that would allow real file filtering (i.e. wildcards, perhaps regex; with include/exclude rules). In fact this has been (partly) requested already (see #24). I have the features listing and design ready since quite a while but didn't have time to start its development. Bonus is we could leave the Apps package dealing with scanning of installed applications only.