Well, here's what i have in mind (anyone else can jump in of course and express any ideas). Please read it all before processing individual parts of it, as some things may be better explained later on. This may require either a separate database (with perhaps a different extension ?) or maybe some significant restructuring of the current one (probably adding things, not altering much the existing ones). My preference would be a new, "superlevel" database, which would just contain info about the multiple databases - one for each datafile.
I'll take as an example the Amstrad CPC TOSEC dats and analyse my idea.
Amstrad CPC - Applications - [BIN] (TOSEC-v2014-10-28_CM).dat
Amstrad CPC - Applications - [DSK] (TOSEC-v2015-05-07_CM).dat
Amstrad CPC - Compilations (TOSEC-v2015-05-07_CM).dat
Excluding the part in the parenthesis (which is actually the TOSEC release), the rest is just a directory structure separated by " - ":
GRAPH(1)
Amstrad CPC
----Applications
--------[BIN]
--------[DSK]
----Compilations
Each actual dat would be in a separate database. When the user adds all three dats from the UI, he would do that in a "superlevel" database which would just contain the names of the three child databases and any other info that may come up in the process (perhaps each database version - the stuff within the parenthesis). The user would have the ability to either open each dat database standalone (as done today) but for easier handling of all of them, he can open the "superlevel" DB which would automatically open the other three.
The UI part now. At the leftmost part of the window (left of the "tabs" area), another tree would be added which would contain what's shown in GRAPH(1) - when the user adds something of course. The names of the folders in the treeview will be taken from the relevant TOSEC dats. The user would be able to define one base path by rightclicking on the system branch (Amstrad CPC). From that, the actual rom paths would be derived for each dat by taking the base path and adding the names of the folders to it. Like this:
GRAPH(2)
Amstrad CPC (an example of the path selected by the user would be: C:\MyData\TOSEC\Amstrad CPC - Plain folder/just organizational)
----Applications (the actual path would be: C:\MyData\TOSEC\Amstrad CPC\Applications - Plain folder/just organizational)
--------[BIN] (the actual path would be: C:\MyData\TOSEC\Amstrad CPC\Applications\[BIN] - Actual ROM path of the respective rdt database file)
--------[DSK] (the actual path would be: C:\MyData\TOSEC\Amstrad CPC\Applications\[DSK] - Actual ROM path of the respective rdt database file)
----Compilations (the actual path would be: C:\MyData\TOSEC\Amstrad CPC\Compilations - Actual ROM path of the respective rdt database file)
The logic behind the setting of the base path is to automatically add a rom path to every new rdt when their databases are created (this could be optional). Doubleclicking on any of the branches marked as "Actual ROM path and also rdt database file" would just open a new tab at the right part of the window, as is now.
An additional idea is for this process (altering the superlevel database - adding, updating or deleting dats and rom paths) to work in an "offline mode". This mode could be a functionality selected by the user (i.e. selecting "offline database modification") on the "superlevel DB". In that mode, the user would add the dat files in the tree, define the base path of each system and add the rom paths in each RDT but while doing that, no actual action will be taken. When he finishes defining everything, he could press an "update databases" button and then all DB creations and rom paths loadings would be made massively. This might require a new window though.
OK, there may be many things i'm missing here but more or less, that's the general idea. I know it's quite some work which might require some restructuring but IMO such an approach would help the user organize things in a way that seems natural and compatible with the dat naming and folder structure TOSEC uses. Perhaps if well designed it will not need much restructuring after all. I've tried to extend the current RC4 UI logic in order to accommodate the multiple DATs logic of TOSEC without making many alterations in the way things work now (which is rather nice).
Closing, please have in mind that the logic of this approach is heavily TOSEC-dependent.
Well, here's what i have in mind (anyone else can jump in of course and express any ideas). Please read it all before processing individual parts of it, as some things may be better explained later on. This may require either a separate database (with perhaps a different extension ?) or maybe some significant restructuring of the current one (probably adding things, not altering much the existing ones). My preference would be a new, "superlevel" database, which would just contain info about the multiple databases - one for each datafile.
I'll take as an example the Amstrad CPC TOSEC dats and analyse my idea.
Amstrad CPC - Applications - [BIN] (TOSEC-v2014-10-28_CM).dat
Amstrad CPC - Applications - [DSK] (TOSEC-v2015-05-07_CM).dat
Amstrad CPC - Compilations (TOSEC-v2015-05-07_CM).dat
Excluding the part in the parenthesis (which is actually the TOSEC release), the rest is just a directory structure separated by " - ":
[b][u]GRAPH(1)[/u][/b]
[quote]Amstrad CPC
----Applications
--------[BIN]
--------[DSK]
----Compilations [/quote]
Each actual dat would be in a separate database. When the user adds all three dats from the UI, he would do that in a "superlevel" database which would just contain the names of the three child databases and any other info that may come up in the process (perhaps each database version - the stuff within the parenthesis). The user would have the ability to either open each dat database standalone (as done today) but for easier handling of all of them, he can open the "superlevel" DB which would automatically open the other three.
The UI part now. At the leftmost part of the window (left of the "tabs" area), another tree would be added which would contain what's shown in GRAPH(1) - when the user adds something of course. The names of the folders in the treeview will be taken from the relevant TOSEC dats. The user would be able to define one base path by rightclicking on the system branch (Amstrad CPC). From that, the actual rom paths would be derived for each dat by taking the base path and adding the names of the folders to it. Like this:
[b][u]GRAPH(2)[/u][/b]
[quote]Amstrad CPC (an example of the path selected by the user would be: C:\MyData\TOSEC\Amstrad CPC - Plain folder/just organizational)
----Applications (the actual path would be: C:\MyData\TOSEC\Amstrad CPC\Applications - Plain folder/just organizational)
--------[BIN] (the actual path would be: C:\MyData\TOSEC\Amstrad CPC\Applications\[BIN] - Actual ROM path of the respective rdt database file)
--------[DSK] (the actual path would be: C:\MyData\TOSEC\Amstrad CPC\Applications\[DSK] - Actual ROM path of the respective rdt database file)
----Compilations (the actual path would be: C:\MyData\TOSEC\Amstrad CPC\Compilations - Actual ROM path of the respective rdt database file) [/quote]
The logic behind the setting of the base path is to automatically add a rom path to every new rdt when their databases are created (this could be optional). Doubleclicking on any of the branches marked as "Actual ROM path and also rdt database file" would just open a new tab at the right part of the window, as is now.
An additional idea is for this process (altering the superlevel database - adding, updating or deleting dats and rom paths) to work in an "offline mode". This mode could be a functionality selected by the user (i.e. selecting "offline database modification") on the "superlevel DB". In that mode, the user would add the dat files in the tree, define the base path of each system and add the rom paths in each RDT but while doing that, no actual action will be taken. When he finishes defining everything, he could press an "update databases" button and then all DB creations and rom paths loadings would be made massively. This might require a new window though.
OK, there may be many things i'm missing here but more or less, that's the general idea. I know it's quite some work which might require some restructuring but IMO such an approach would help the user organize things in a way that seems natural and compatible with the dat naming and folder structure TOSEC uses. Perhaps if well designed it will not need much restructuring after all. I've tried to extend the current RC4 UI logic in order to accommodate the multiple DATs logic of TOSEC without making many alterations in the way things work now (which is rather nice).
Closing, please have in mind that the logic of this approach is heavily TOSEC-dependent.