ThomasAdam wrote:OK, thanks. I've taken a quick look, and although some of the changes look OK, a lot of the helper functions you've added for file-path finding, etc., would naturally go away when you start looking at using autotools for the prefix directory locations for system-wide files, as well as XDG for user specified locations. XDG is the important standard to follow here since it's designed to allow for an arbitrary directory structure. I can see you've had a stab at it.
So how do these helpers go away? I can imagine that autotools can be used to set the expected directory for system files, i.e. somewhere under the installation prefix, but what of the things under the user's home directory, i.e. $HOME/.config? Something has to expand the environment variable and construct the pathname from it. Autotools can't do that because it cannot forsee who the user running B-Em will be or what they home directory will be so it cannot construct that path statically.
ThomasAdam wrote:I'm not sure we need a different implementation for Windows/Linux in terms of find_dat_file() and friends -- POSIX still allows for "/" in file paths, even on Windows.
It is not so much a case that how a directory are filename are joined together needs to be different but that the set of directories to search needs to be different on Windows.
I think what's needed here is:
- A common set of functions for traversing a known directory structure -- the paths are separate from the files themselves and hence one implementation can work for both Windows and Linux.
- The directory structure should probably look something like this:
That is to say, the emulator ROM for the model is the same name (hence, loaded first), and then all other ROMs for that model.
Code: Select all
- Using autotools for the system-wide locations will involve additions to config.h so that these are accessible -- this will thankfully make the current set of file-location functions simpler.
By emulator ROM
did you mean OS ROM
? That isn't that different from what we have prior to my most recent change, except that the OS ROMs are not in the sub-directories for the models they apply to, possibly because the same OS is used by several models, but then the same is true of basic and some other ROMS. Also, except for the fact the existing arrangement allows the ROMs to be named with a leading number to force them to load into specified slots which is sometimes needed if two or more ROMs offer the same service or command and you want to choose which one should get priority.
ThomasAdam wrote:The structure above would be the same for system-wide, too. Additionally, in terms of the user overriding things themselves -- because ROM-loading is dynamic in terms of what's available, I think it best to introduce a dialogue which indicates the ROMs which are loaded, and for that to be configurable.
There doesn't seem to be much in the way of widgets in Allegro 4. It does look like the building blocks may be there to build a dialogue that is not either a message box or a menu but it doesn't look trivial. It would be good to have a dialogue to manage ROMs, though. Is such a GUI sometime to postpone until Allegro 5 or could it be done now and ported forwards?
ThomasAdam wrote:To do this, what I would recommend is getting b-em to copy into $XDG_DATA_HOME the ROM structure and always using that, regardless. Although it used to be the case that Unix programs shouldn't randomly install dot files for the user, that idea seems to have died out. Additionally, if we were to update ROMs, we can handle that via update hooks when we release new version of b-em.
Except that the package installation hooks run as root for the system as a whole and probably shouldn't be searching all user's home directories to find things to update, though of course it is possible.