tl;dr notice: proposed data search paths for each platform are at the bottom of this email.
On 11 Jun 11, at 2:31 PM, Glen Ditchfield wrote:
> On June 10, 2011 10:11:20 Jeremiah Morris wrote:
>> If Aleph One for Windows had the capability to auto-install the default
>> font and theme files, it'd make sense for them to live in
>> CSIDL_LOCAL_APPDIR too; that would be equivalent to the inside-the-bundle
>> directory in the Mac version.
> The inside-the-bundle directory isn't user-specific and the files are static. The
> last row of the "Known Folders" table at
> recommends CSIDL_PROGRAM_ FILES (C:\Program Files) for that case. The next
> paragraph notes that the executable might actually be installed in some other
> folder, so it recommends using a path relative to the executable -- which is
> what Windows AlephOne does now.
That would be the correct behavior if we had an installer process, which created the executable along with these default files. I was thinking of a "self-healing" scenario, where at launch, Aleph One would write the fonts file whenever it noticed it was missing -- in that case, the user launching Aleph One may not have permission to write to PROGRAM_FILES. In that case, COMMON_APPDATA would actually be most appropriate (not LOCAL_APPDATA as I'd said).
At any rate, we have no plans to add either of those features; Microsoft will probably have new guidelines before we reach that point!
> On Unix, the inside-the-bundle equivalent is prefix/alephone (e.g.
> Windows and Unix process this directory differently from MacOS, though.
I think you're misunderstanding how the code currently works -- the "inside-the-bundle" code is specific to Mac OS X, and doesn't exist at all for Windows and Unix. For the directories in my previous email:
5. System-wide plugins and scripts, for use with multiple scenarios
Windows default: [executable path]\Prefs\[user name]
Mac default: ~/Library/Application Support/AlephOne
Unix default: ~/.alephone
6. On the Mac, there's a directory inside the app bundle, with the default font and theme files
Windows default: variable does not exist (#ifdef'd out)
Mac default: [executable bundle]/Contents/Resources/DataFiles
Unix default: variable does not exist (#ifdef'd out)
7. Directory argument or fall-back location
Variable: argument in arg_directory, fallback in default_data_dir (except on Mac)
Windows default: [executable path]
Mac default: result of getcwd(), which is executable path when run from the GUI
Unix default: $PREFIX/share/AlephOne
I'm not saying this is how it should be in the future. I just want to make clear that the Mac bundle directory (path 6) and the no-argument fall-back location (path 7) are separate from each other.
As mentioned earlier, the search path goes 7 -> 6 -> 5. For the sake of argument, let's shuffle the Unix defaults to:
7 fall-back: nothing
Is it fair to put prefix ahead of the home directory in terms of defaults? Would it instead make more sense to have argument, then ~/.alephone, then /usr/local/share/AlephOne? Do we need the ability to suppress any of those?
For Mac and Windows, the fall-back behavior of 7 is useful and matches prevailing usage. (The non-GUI wrinkle of the Mac, though, is not important.) As you mention, Unix use cases would nearly always have an argument, so a fall-back may be unnecessary there. The current instructions say to place game files into the prefix location, and don't mention the other paths, so the shuffling would not cause problems for users who ignore the directory argument but follow the default instructions.
For the Mac, 6 comes ahead of 5 to allow the distribution of a single scenario + executable bundle. As I argued earlier, I'm not in favor of bundling this way. I'd prefer 7 -> 5 -> 6, so anything in the application bundle is loaded last. That order would also work for the Unix defaults as stated above, treating prefix as the last resort for program defaults.
For Windows, the current path 5 doesn't map terribly well to any of these concepts: it's both user-specific and relative to the executable, making it unsuitable for either user or program defaults. We don't really need a 6 right now; for compatibility, we could use the current path 5 in its place, or make it something like [exe path]\DataFiles like the Mac's bundle. For the "proper" path 5, where users can install scenario-independent content, we'd want something in CSIDL_PERSONAL.
With all that, we'd get search paths that look like this:
Unix: [directory argument]:~/.alephone:$PREFIX/share/AlephOne
Mac: [directory argument, or executable's directory]:~/Library/Application Support/AlephOne:[application bundle]/Contents/Resources/DataFiles
Windows: [directory argument, or executable's directory]:$CSIDL_PERSONAL\AlephOne:[executable's directory]\DataFiles
That follows a standard pattern of: selected current scenario, then user's installed extras, then program's defaults. Comments?