Re: [AD] standard path updates

[Matthew Leverton <meffer@xxxxxxxxxx>]

On Tue, Mar 1, 2011 at 7:19 AM, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> The problem is this: hard-coding the path like that on Windows disregards operating system localisation.
>
Of course. You would call the proper Win32 function to get the name of
ProgramData. But without that al_set_directory function, how is
Allegro supposed to know that's where you decided to put it? (As
opposed to local data or in My Documents, etc.) It cannot, unless you
tell it somehow.

You could set the Allegro app name and make it the convention that it
*must* be in C:\ProgramData\$AppName. (Although that location was
introduced in later versions of Windows, so it isn't quite so
straightforward.) However, maybe the programmer bundled data, in which
case you wouldn't want to return that. So you'd need a different
constant (not RESOURCES) to indicate the system read-only data folder.

In Linux, when done via ./configure, the user might just choose
whatever folder he would like. That does not necessarily translate to
setting app-name, which is why I suggested that we would need a
separate function to set the program data path. I don't like the idea
of just guessing at file paths that look like they might be correct
based on a hunch.

I don't think anybody disagrees that it would be nice to have a cross
platform way of detecting where program data has been installed, but
that's really just not possible to know for sure at run time unless
Allegro has been given a hint.

I think having a guess-work solution is worse than having none at all.

> Related question: on Linux, does asking for the resource path resolve symbolic links in the path?
>
It was discussed and the consensus was that it should, but as far as I
know, it does not. I didn't know what the proper way to do that was,
so I left it unimplemented and asked for somebody else to add that
part.

I would not, however, resolve EXENAME, but there wasn't agreement on that.

--
Matthew Leverton