In multiple situations it’s inappropriate to automatically remove not-found files from the Recent Files list. Just some examples I’ve experienced myself:
- Sometimes the file may be on a temporarily-unavailable network share.
- Sometimes the user may have moved/renamed a folder, and needs the original name for reference.
- Other users may just want the recent file history without Blender deciding to clean it up.
I believe a less opinion-imposing alternative, and more-ideal default (“smarter” than other software), would be to:
- Keep a count of failed opens
- Do not delete the file from the list on the first failure
- If the user tries again, any time, the fail count will now be >=2, so pop up a dialog, “This file was not found {n} times. Remove from recent files list?”
The above would require the meta data stored in the recent files list. A backwards-compatible method could use # commented lines (or whatever), with the meta-data in it. (Perhaps other meta data could also be useful for recent files, like last open date, count of opens, etc. Things that could allow for smarter project-listing dialogs. Maybe you’ve worked on a project 100 times, but it’s not in the last {recent_files_count}, it could be retained as one of the Favorite Projects. The meta-data would be forward-compatible with new features, but perhaps a #comment hack may not be the best solution in that case. Also, how do we handle newlines in the recent-files.txt? I’ve not looked into that. We could examine if it were a plain [old] format, or a new format with each file’s info on one line:
path=/path/foo.blend,openfails=3,opens=5,mtime={datetime},pin=false
path=/path/mainproject.blend,openfails=0,opens=150,mtime={datetime},pin=true,favorite=true?,category=3d-Printing
Alternatively, have auto-remove be a user-preference.
(This wouldn’t allow for “favorites” (pinning?)
(I also added “Category”, but I think we’d probably not want to get that elaborate, leaving that organization to the user in their own filesystem.)