h.g. muller wrote:
I guess it does not really matter what the user specific
configuration file is except I think it should
definitely not be ./xboard.conf. That would mean that the xboard
configuration would depend on
the current directory which would lead to all kinds of surprizes
(e.g. engines would use 64M hash
in one directory and 128M hash in another directory).
But that is exactly why I like it. I typically run WinBoard through a
Tournament Manager, which
gives me no control on what is on the command line that invoked it.
This seems to be a problem which should be fixed in this particular
Tournament Manager.... I just checked the documentation of
"tourney-manager" (which comes with Ubuntu) and it allows
straightforward control of xboard's command line arguments.
So the only way to control
the WinBoard settings is to write them in the ini file in advance. And
when I run two tournaments
in paralel, one might need -variant gothic and the other -variant
normal. There would be no way
to do that if all invocations were forced to use the same ini file.
(Even for WinBoard I can only
do it by having two copies of winboard.exe, to have different install
directories. Inelegant, but
at least it works.)
The customary way to deal with this situation is to provide xboard with
a command line argument to select an alternative configuration file.
This command line argument could be provided by the tournament manager.
As to the configuration problem: When the default settingsfile is
/etc/xboard/xboard.conf, and
the user will try to save the settings (and -saveSettingsOnExit true
is compiled-in default...),
it will either work, or he will get an error popup mentioning that
this file could not be opened.
I guess it could be expected from Linux users that they then are smart
enough to actually
create the directory it is supposed to be in, and make it writable to
them.
A freshly installed user program that wants to write by default to a
system configuration file (i.e. one in the /etc directory) would be
*very* uncommon in Linux (and against the very idea of system
configuration files which are supposed to be shared by all users).
There is usually system wide configuration file (or directory) created
at install time and a user specific one created when the user runs the
program for the first time. For example I have /etc/firefox-3.5 and
~/.mozilla/firefox-3.5/ (and I wouldn't expect firefox to dump a
configuration file in every
directory I run it from....).
In easy cases it is possible to dispense with the system wide
configuration file.
We could also provide a "make install" target in the Makefile, which
puts the directory there.
