RomCenter wrote:A list of available dat in the tree is a good idea, but I have to find a good solution to display databases and datafiles together.
OK, taking the idea from another program (i believe it was TOSEC's TIM), i'll try to describe below a procedure i have in mind. I'm brainstorming here in an attempt to generate ideas on how to implement everything in a tree, i'm not saying i've thought of everything. The idea is to have one tree structure only, containing a combination of the database and the actual rom folders contents and show each of them in different colors according to whether it is proper, fixable or unfixable (green, yellow or red). Filtering should of course exist, perhaps as is now (separate buttons for rom folders and db items).
1. The user creates a new database, blank at the beginning, he just gives a name.
2. He decides which dats it will contain, so there should be an "import dat" procedure. In that dialog, there could be a "create subfolders from filename" checkbox to define if the dats names are segmented (or "TOSEC-style" compatible). I'm using TOSEC as an example because their dats filenames have specific format (items separated by dashes). In the same dialog, he could define the separator (dash in TOSEC's case, in other dats it could be something else). Each item in the dat filename could be converted to a folder in the tree, for instance "Amstrad CPC - Applications - [DSK] (xxxxx)" could appear as Amstrad CPC\Applications\[DSK] (the (xxxxx) at the end should be discarded), so the database branches would be filled by the dat's filename and the actual files would be shown in the list when the last branch of the tree is selected (i.e. [DSK]).
3. The user could also mass-select dats and add them to the database or update an already existing database structure if a previous version of the dats has already been inserted to it. Branch (name of the db folder) renaming should be possible in case it's needed. Perhaps a "change rom folder loction" should also exist, in order to be able to keep the cached contents of a rom folder in the db and just change its location/name (eliminating the need to close and reopen the rom folder which is time consuming).
4. In order to select the rom folders, the user would be able to right-click on a tree folder and through a menu item (i.e. "Select rom folders"), select the data folders bound to that tree item. The selection dialog could have a "recurse" checkbox so if someone has a rom folder containing a subfolder structure which is the same as TOSEC's naming (name of the tree item should be the same as the name of the folder on the disk), he could select the main folder (i.e. "Amstrad CPC"), define a roms location for it and RC would bind every subfolder of the tree to the appropriate rom folder on disk.
5. In the tree, each item could appear with the normal RC color coding (green, yellow, red, dark grey for unknown files/roms). In the tree, completely missing roms (zips existing in db but not on the rom folder) could appear with a different shade of red or perhaps light grey).
Notes:
- This idea is pretty straight-forward assuming there is a 1-1 relationship between db folders and rom folders. If one wishes to have more than one rom folders then it becomes a little complicated. In order to view a specific branch, perhaps in the rightclick menu of the tree folder, there could be a "open in new tab". Then RC would open a new tab which would display the specific db folder only and its roms folders of course in the same way as RC 3.x currently does. Just the selected db folder, not subfolders (if it has any).
- In every folder of the tree, other items should exist in the rightclick menu (i.e. "fix folder", "reload", refresh" and several others currently existing in RC3.x).
- In the top level only, a "rom bucket" could exist in order for the user to be able to define folders containing roms he does not know where they belong or what their correct name is. Those should be checked against every dat file in the tree (perhaps only manually because i guess it could take quite some time).
- For simplification reasons, this idea assumes that all roms are compressed. I guess an "uncompressed roms" structure of the type "FOLDERNAME\ROM FILES" would be pretty difficult to support together with all of the above, except if there could be a way for the user to define that a selected rom folder is "uncompressed" (its contents are in the form "SUBFOLDER\ROM FILES").
RomCenter wrote:For example, in the current implementation, it is quite simple to display a dat without importing it in a database. Of course, you couldn't add any rom folder in it.
The user could still load the dat, as is currently done. A "Save in database" could be added as a menu option and then the dat could be saved in a new or added in an existing db.