Thanks for your feedback.
I have a confession to make - I'm not *that* interested in the installation/OPK side of the software; my interest is in porting and then optimizing the actual emulator and getting the games running as smoothly and as excellently as possible. I like solving problems when particular games don't work. I like making new games work. I like making things go faster.
However I do want to make it all work
The installation part of the project doesn't motivate me very highly. For this reason I tried solving the issue of the relatively complex file structure and various paths in easiest way possible from my point of view - which does deviate with the standard way other people have packaged their OPKs.
As for offering the user the exact ROMs directory location, this approach isn't really sufficient in this case - if you want to offer the user flexibility then it should be able to define exactly where everything goes.
For XMAME the following directories are used in each of the three versions of XMAME I've offered:
That's a lot to take care of and choose where everything goes, as that is multiplied by three.
Some of these contain content supplied by the user: roms, snap, samples, artwork
Some of these contain files which will be generated by XMAME: snap, cfg nvram, memcard, inp, hi, sta, frontend
Some may be a bit of both.
Some of these directories could be shared amonst versions of MAME: roms, snap
Whilst the remaining must be specific to the version of XMAME using it.
So how much user control do you offer?
Well be default, XMAME actually does offer full control - if you want. I haven't changed the way XMAME works - the user could in theory change where everything is.
However, and this is the big but, on a handheld console, lacking a keyboard, configuration of all these paths and files is difficult and tedious.
So, for simplicity, I decided on limiting the installation choice to either "internal" or "external" and XMAME taking care of the exact locations of all these paths/files I listed above. Whilst not consistent with the regular GCW approach, I felt that in this case this was an OK solution. After all, does it really matter exactly where the user content is placed on the storage? Do most users really care? I wouldn't think so in most cases, but there are of course always people who do.
That's why I created the XMAMEROOT environment variable concept so adopting the read-only OPK approach is feasible with not too much having to change.
I'll fix the current installer to work with FAT32 but after that for the next release I'll have to think about how things perhaps could be changed or if just kept as-is.