Re: [AD] set_config_file jumping around on OS X bundles

[Grzegorz Adam Hankiewicz <gradha@xxxxxxxxxx>]

On 2005-08-21, Elias Pschernig <elias@xxxxxxxxxx> wrote:
> On Sun, 2005-08-21 at 14:06 +0200, Evert Glebbeek wrote:
> > set_config_file("mygamesconfigfile.cfg");
> > allegro_init();
> > would not be allowed while
> 
> Yes, makes sense, but the docs currently say:
> 
> "You can call this function before install_allegro() to change
> the configuration file, but after set_uformat() if you want to
> use a text encoding format other than the default."
> 
> Now I think, we should remove that paragraph (and therefore
> disallow calling it before allegro_init).

But then you disallow having configuration settings in a .cfg file
which is not named allegro.cfg. At worst, you will have two .cfg
files if the programmer is not careful, and depending which are on
which file allegro_init may ignore something set by a confused user
on a different configuration file.

Let's say I have a game called PUCKMAN, and my Windows binary
is packman.exe.  So I do:

  set_uformat(U_UNICODE);
  set_config_file("puckman.cfg");
  allegro_init();

And now Allegro will read the configuration from packman.cfg,
rather than having both allegro.cfg and puckman.cfg in the same
directory. And if I distribute setup/setup.exe I'll tell it to save
the settings into puckman.cfg. All with the purpose of customising
the game as much as possible.

In fact, you could distribute several Allegro binaries in the same
directory and they should not need to pollute the same allegro.cfg,
and under Linux you would like to have this feature because otherwise
all games would use "allegro.cfg" and each would try to overwrite
settings created by another game (see recent thread pointing this
problem with language.dat, which is pretty much the same, and whose
solution is "well, put everything together in a separate directory
and look in another direction).

Finally, the "special" code was for those games where somebody
just copied a binary to somewhere else and the game code
calls set_config_file but the file is not there and an IO
error happens. That doesn't have anything to do at all with the
problem Matthew reported (or at least I look at it on a different
level). See:

  http://sourceforge.net/mailarchive/forum.php?thread_id=5254813&forum_id=34598

cvs annotate is your friend.

> This would hopefully also solve the OSX problem.

The OSX is completely unrelated and it just calls for a design
decission. First of all, is the configuration for a game meant to be
stored inside a bundle? I would say yes, but unfortunatelly Allegro
doesn't understand several config files at the same time, like a read
only one inside the bundle and a user specific in the user's home.

So I would solve the problem by disallowing all configuration
routines work with files inside the application bundle, and use
"~/..." as prefix. After all, if an administrator installs a game
in the Applications folder, should a plain user be able to modify
files inside the Applications resource folder, potentially afecting
all users on the system?

We shouldn't be trigger happy with solving problems, how ever much
that may hurt releasing 4.2.0. I believe there is another problem
with get_executable_name under OSX, with returning the path to
the binary inside the bundle or the bundle directory. Again, this
is a design decission, which didn't rise before because certainly
bundles are something new to Allegro.

Just like how "#" could mean "read inside bundle structure" under
OSX instead of "read inside datafile appended to binary"... to
make it more cross-platform... Too many decissions, and not enough
experienced coders for OSX, it seems.