cathoderaydude
commented
3 weeks ago I've just realized my PR had an unintended effect, but I'm not sure it's a bad one.
I changed code in two places, not realizing the first one - under _"filebrowser_type == FILEBROWSER_SELECT_FILESUBSYSTEM" - applies when "Filter by current core" is enabled. With my changes, that setting is now overridden by "Filter unknown extensions." So we have the following behavior:
- Set "Filter by current core = Yes"
- Set "Filter unknown extensions = No"
- Load an NES core
- Navigate to a Genesis ROMs folder
- Despite an NES core being loaded, you see the Genesis ROMs.
I feel this is desirable, because I don't think anyone would set "Filter unknown extensions = Off" unless they were doing diagnostics of some kind: checking if RA is able to read a given folder at all, trying to feed a file to a core that isn't listed in the compatible extensions, or something similarly unusual. I think anyone in that situation would want this to be a brute-force, "show me everything, no matter what" setting that overrides any related convenience features.
So IMO, this new behavior is probably what most people would want. If there's no disagreement on that point then the change can stand, otherwise you'd just have to revert the first line and leave the second. Ty!
Description
The "Filter unknown extensions" setting is only honored in ordinary directories, not inside archives.
Expected behavior
When opening a zip file containing a file that is not compatible with any installed core, if "Filter unknown extensions" is off, I expect the file to be visible.
Actual behavior
The file is not visible, usually resulting in a zip that appears empty.
Steps to reproduce the bug
Bisect Results
I'm afraid I don't know how to use bisect.
Version/Commit
Environment information
Fix
This seems to be due to a missing check in menu_displaylist.c. I've added checks against filter_exts during calls to the filearchive methods, and in local tests it appears to fix the issue. I will submit and link a PR momentarily.