Wishing an option to selectively "keep search results / branch view" tabs in memory
Posted: 08 Jul 2024 10:55
Hi Don,
as noted in other threads, the option "Cache search results" in the configuration is practically useless, since it can be even slower than a completely new / repeated search, when switching tabs back to that search results / branch view tab. This seems to be true at least for long resulting lists, where the idea of not wanting to repeat a search, would really make the most sense.
But what about keeping the whole search results or branch view tab in memory when switching tabs away from it? Then, when I come back to that tab, it should just behave as if I never left it, no delay of any sort whatsoever, right?
Of course, I understand that you might be worried about memory overflow or whatever it is called.
Therefore, the decision of whether to keep search results tabs in memory could be based on the number of open search results tabs. Only keep MAX the most recent X search results tabs in memory. This number could be specified in the config. It could also be based on the (min) number of found items. Or both, the (min) number of found items and max number of search tabs.
In the UI, similar to the "Cache search results" option, there could be an option as "Keep this number of most recent search results tabs (incl. branch view) in memory (while they exist)" (or similar) and changing the label of the input field to "number of most recent search results tabs (incl. branch view) kept in memory (while they exist)" (or similar).
And another similar option "Keep search results tabs (incl. branch view) in memory if MIN X found items" (or similar) and changing the label of the input field to "MIN number of found items to keep search results tabs (incl. branch view) in memory" (or similar). Yes, the MIN would be correct because I would want to avoid the reload/research especially with long result lists. Thus, I could have a lot of "small" searches open in the background that do not affect the memory.
Of course both options should be connected with AND. Both must be fulfilled for the tab to be kept in memory.
BTW, the search results bar (blue on top) could indicate whether those are cached search results or a memory-stored search results or none of both.
And there could be a branch view bar stating similar info.
I know, this probably would be a big change and big changes are scary so I assume it will not happen. But just as a food for thought I posted it anyway. Maybe the is a small chance that it will come one day.
regards
as noted in other threads, the option "Cache search results" in the configuration is practically useless, since it can be even slower than a completely new / repeated search, when switching tabs back to that search results / branch view tab. This seems to be true at least for long resulting lists, where the idea of not wanting to repeat a search, would really make the most sense.
But what about keeping the whole search results or branch view tab in memory when switching tabs away from it? Then, when I come back to that tab, it should just behave as if I never left it, no delay of any sort whatsoever, right?
Of course, I understand that you might be worried about memory overflow or whatever it is called.
Therefore, the decision of whether to keep search results tabs in memory could be based on the number of open search results tabs. Only keep MAX the most recent X search results tabs in memory. This number could be specified in the config. It could also be based on the (min) number of found items. Or both, the (min) number of found items and max number of search tabs.
In the UI, similar to the "Cache search results" option, there could be an option as "Keep this number of most recent search results tabs (incl. branch view) in memory (while they exist)" (or similar) and changing the label of the input field to "number of most recent search results tabs (incl. branch view) kept in memory (while they exist)" (or similar).
And another similar option "Keep search results tabs (incl. branch view) in memory if MIN X found items" (or similar) and changing the label of the input field to "MIN number of found items to keep search results tabs (incl. branch view) in memory" (or similar). Yes, the MIN would be correct because I would want to avoid the reload/research especially with long result lists. Thus, I could have a lot of "small" searches open in the background that do not affect the memory.
Of course both options should be connected with AND. Both must be fulfilled for the tab to be kept in memory.
BTW, the search results bar (blue on top) could indicate whether those are cached search results or a memory-stored search results or none of both.
And there could be a branch view bar stating similar info.
I know, this probably would be a big change and big changes are scary so I assume it will not happen. But just as a food for thought I posted it anyway. Maybe the is a small chance that it will come one day.
regards