Bottom line is: I don't really think this matters greatly. It's certainly not something I'd complain about as a significant issue personally.VincentVega wrote: ↑Wed Oct 17, 2018 7:53 pmIf anyone else has views on my use of "Application Support", then please let me know - if the prevailing view is that people would rather me use something else, then I'll change the patch.
The Windows/Linux versions of RPCEmu will load the support files from the same directory as the executable. On a Mac, this would actually be inside the application itself, namely in the "Contents/MacOS" folder, which is why I changed it. From looking at the source, Caliston builds look like they prompt you for a data directory on first start-up - would this be a better approach?
However, my take on it would be this.
It's important to follow Apple's guidelines, I agree (and there's plenty of evidence to show the wisdom of doing so, when Apple later does something that causes your software to break if you haven't heeded its advice!). Nevertheless, buying files that you may need to access regularly within Application Support, which is tucked away in the hidden-by-default Library folder, is really unfriendly and not at all helpful. I think the clue is in the name: Application Support is for support files for applications: files that apps need in order to run, but that the user typically shouldn't need to see. So if you've got a simple all-in-one package that you can install wherever you like by just dragging it – as is the case with most Mac App Store apps – it makes sense for such an app to silently keep its external resources tucked away in Application Support.
But with RPCEmu, changes are high that the user will want to access the support files pretty frequently. Indeed, for a whole working system's entire hard disk-based structure to be hidden away like that is pretty nonsensical when you think about it. Indeed, I've put my own 'simple' RPCEmu boot disk in Documents/RISC OS for easy access, and have pointed HostFS to that via a symlink; and then I've got separate symlinks within that to point to my main RISC OS storage on my NAS as well as other places.
I agree that moving things outside the application bundle is basically a good idea – not least because you don't want to destroy your data and settings if you upgrade the app! But I'd suggest that the support files could go EITHER in Application Support OR alongside the RPCEmu app in its own applications folder, for easier user accessibility. Alternatively, if you do put the files in Application Support, perhaps you could include a draggable alias to install along with the application, pointing to the home of the files in Application Support. That would allow people to access them easily and thus remove a lot of the problem.
As for prompting the user for a data directory at start-up… I think that's basically a good idea, but maybe not the whole story. How about…
1. Look for the support files in Application Support
2. If not found, look for them alongside the RPCEmu application itself
3. If still not found, prompt the user to locate them via your suggested data directory prompt.
This could also, of course, tie in with the proposed options to choose between multiple configurations.
NB It would be up to the user to ensure that data directories weren't present in both locations 1 AND 2! If they were, the one in Application Support would of course take precedence. Actually, perhaps that could be a good thing. If the user messes up their RISC OS boot sequence, for example, they could move it temporarily out of Application Support, and then if there's a simple bare-bones version installed by default alongside the application itself, that would be picked up and used as a fall-back position.