Re: [XBoard-devel] links [installer]

[h . g . muller]

Op Ma, 27 juli, 2009 7:42 pm schreef Eric Mullins:
> [There's also -settingsFile, which may just be an alias for -ini]

Indeed, it is.

> I'm still not clear on the difference, if there is a difference.
> Although I have used -ini for years, and I'm pretty sure if given, that
> winboard.ini is neither read nor written to if some other .ini is
> specified.

Can you be sure it is not read? Perhaps it is read, and then simply
overruled by the file of the settings in the -ini argument. From looking
at the code it seems always an attempt to read winboard.ini is made (after
initializing everything to compiler defaults), and only then the command
line is parsed. If @<file> or -ini <file> is encountered in the command
line, the contents of the file is inserted at that point. The difference
is that the -ini argument is remembered for later saving; the @<file>
arguments are never overwritten.

> Perhaps the @<inifile> syntax allows merging (taking
> precedence over) settings with the main .ini being used?

This is in general how it works. Later settings overrule earlier settings.
The order is compiler defaults, winboard.ini, command line (with .ini
files inserted).

> The .ini files specified in the links which you are using the "@" syntax
> tend to be very small.  Maybe for the shortcuts, we can:
>
> 1) call -ini <inifile> where it resides somewhere in AppData
> 2) AND @<mergeinifile>

Yes, this is possible.

>
> I'll have to test that, but I'm suspecting that saving settings will
> then properly go under the AppData directory, and we can keep <mergefile>
> in the install directory since it doesn't get written to.
>
>
> [OT]
> What always irritated me is I would create a custom INI file for
> something like running an engine.  I'd save settings, and then certain
> settings necessary for running an engine would be overwritten, and I'd
> have to fix the INI file.

This is why the @<file> arguments are so useful. The settings for the
engine go in there, and are never overwritten when yoiu save settings.
Unlike an argument giving as -ini.

> This was usually because I wanted to update
> JUST the window positions, but I've learned I can't do that because it
> clobbers other settings necessary for it to operate.  Perhaps my solution
> is to have a main .ini file that contains mostly just the window position
> settings, and have a mergefile (@ syntax) that contains all the settings I
> don't want altered.  I'll have to try that.
>
>
> It's basically the same idea as running xboard from a script.  You
> specify all the command line options you want instead of using an .ini
> file.
>
>
> Oh yeah, we'll keep the shortcuts.  I'm just investing how they need to
> be done is all.
>
>
> That's an issue to be sure, but the problem isn't so much about
> multi-user as it is about permissions. There's no permission to write in
> the program files directory except for administrators.  Vista and Win7
> default to non-administrator accounts.  It's a headache the entire windows
> software industry has had to deal with.  We don't want users to have to
> click the UAC confimation every time they run winboard.
>
>
> They don't-- I made a mistake.  I was talking about putting the writable
> .ini files in the user's appdata area, and was thinking it would suck to
> have to copy the complete winboard directory structure for a few .ini
> files.  The logo files being read only, can stay in the programfiles
> directory.  I don't know if we'll run into problems finding the logo files
> though.  I haven't looked, but I assume the logo files are expected to be
> in the same directory as the invoking .ini.  You can't know the path in
> advance, so the path can't be in the .ini file, so at best it could be
> ".\logo.bmp" or something.

WinBoard will search the logo files in the same directory as the engine
executable, but the .ini in its own directory. The .ini can contain the
engine directory as -fd or -sd argument. It is possible to give explicit
logo pathnames, if for some reason the -fd setting has to be different
from the engine directory. (Usually because you are explicitly invoking
Polyglot, and the engine directory is specified in the polyglot.ini file
that WinBoard knows nothing about). But the idea is that with -autoLogo
true WinBoard should automatically find most engine logos, and also logos
for ICS or human players in the ./logos folder.

> If that's what's being
> done, then you can't just put all those .ini files into one directory,
> because they want different logo.bmp files.