Now that the severe performance issues are addressed (#123, #205, #247 etc etc) it's high time we had the refresh APIs reworked as already discussed in commit messages and other issues here. Opening this to have commits refer to a common issue and to start investigating. In short:

• more granular refreshes (avoid refreshing the whole list or rescanning the data dir when we know what changed):
  • RefreshUI should accept deleted, modified (currently files) and added parameters and act accordingly (f65b068)
  • Same goes double for refresh() -> that was a saga see 6a5e338
• BAIN RefreshUIMods should be made aware of bsas -> c6ec399
• prune all refresh() calls outside the data model -> edit 11/2023 rather prune refresh satellites (delete_refresh...) and clearly mark cached_lo methods that do refresh -> done spanning several merges - especially the ut-353-336 ones and Load Order Handling Improvements, Part 2 #578 for load order refactoring (see also _lo_op decorator). Some notes in d2f3a5b
• investigate scanning Data folder once - we scan for BAIN, bsas, mods... (4101778 ) -> Refresh Optimizations III #701
  • As an extension of this, we should have one central place where we can dump an update (i.e. something like handle_changed(added, updated, deleted)) which then propagates to the right handlers (ModInfos, BSAInfos, etc.) instead of us having to do that manually - this will enable Event based refreshes #265 -> this is out of scope but the tools are here

Nit in UI:

• RefreshUI details (81cacb1) and selection handling parameters
• ShowPanel (->RefreshPanel) API reworking to pass on the parameters to refresh/ui - also comment it and clean it up to be used everywhere

Nit in BAIN:

• in BAIN refreshTracked we should pass the changed crc, size, mtime in instead of recalculating them - see ebbdc79

This is not so much for performance (although scanning the data dir and redrawing all items is measurable performance) as for code stability and maintainability and elegance.

Plus blocks #265 - we can't switch to an event based model without robust deletion/addition/modification handlers