activity-browser
activity-browser copied to clipboard
Show open databases as tabs
I'd like to suggest of instead of having databases open 'one at a time' to move the entire activities widget (including the search) into tabs, one for each open database. This solves 2 issues:
- Search can be preserved for different databases
- Users can easily switch between open databases that they are working on or are viewing
We could move the name of the db to the tab, also providing more space for the search bars.
It would also be nice to have a right click option on the 'database tab' to close the database, or just a close button, removing it from the tab bar again.

Half related: #632
I see how users could like this. Also the preserved search/filtering.
I have no major objections, only:
- it will make the code more complex by adding and managing another
QTabWidget; all loaded database tables will stay in memory via theMetaDataStorealready, so reloading a database is quick; but I agree that this could be even quicker and could, potentially reduce the need/dependency on theMetaDataStore.
Thanks!
it will make the code more complex by adding and managing another
QTabWidget
Agree, I'm not sure how complex handling signals would be if we have multiple instances of the activities widget, where we currently only have one that we just update. This would be something to look into in detail before we decide to have a go at -or not-.
... but I agree that this could be even quicker and could, potentially reduce the need/dependency on the
MetaDataStore
Not sure what you mean here? MetaDataStore is useful in my mind and I don't see how we could make this faster than reading from memory. Why would we want to reduce this dependency?
One of the reasons I originally created the MetaDataStore is that it takes a couple of seconds to load the metadata for all activities in a database. So when switching to another one and then coming back to the original one, it can - instead of reading it from the database again - read it from the MetaDataStore, which is faster. Now your idea of storing the metadata in separate tabs, basically provides the same as this data is now stored (in memory) across the tabs. So in a way it does not require the MetaDataStore for this specific application anymore. I have not thought further than this, so it could well be that keeping the MetaDataStore is a good idea still since it also provides the metadata in the LCA Results/Inventory tab etc.
Personally, I like keeping it, it is indeed also useful in LCA results. Additionally, I was also using it for the new modular LCA implementation, as is indeed also useful there for the metadata.