Re: [XBoard-devel] links [installer]

[Eric Mullins]

address@hidden wrote:
> Op Ma, 27 juli, 2009 4:45 pm schreef Eric Mullins:
>   
> > Ok, what does the "@<inifile>" syntax do that's different from "-ini
> > <inifile>" then?
> >     
>
> I was not even aware that argument existed. I looked in the code, and it
> seems the -ini or -settingsFile option is used to set the main settings
> file, i.e. the one on which you also save on exit or using the menu.
> (Although I don't see how this could work to perevent reading
> winboard.ini, as command-line options are only processed after
> winboard.ini is read, to make sure that the command-line options overrule
> the saved settings.
>
> With @<inifile> the options in the file are processed, but its name is not
> remembered, and saving of settings will take place on the main ini file.
>   

[There's also -settingsFile, which may just be an alias for -ini]

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.  Perhaps the @<inifile> syntax allows merging (taking 
precedence over) settings with the main .ini being used?

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>

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 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.

> > Maybe I'm not understanding the implications correctly here.  But to me
> > that seems like a lot of work, and at the same time, giving up important
> > functionality for invoking the program because it's flexible and limited
> > only by one's imagination.
> >
> > 4.2.7 used a combination of .BAT files and shortcuts to run in various
> > ways.
> >     
>
> I never understood how to use the .bat files of 4.2.7.
>   

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.

> I do know that 4.2.7 did have items in the start menu for running winboard
> as game viewer, as game viewer with 2 different games autmatically loaded,
> on ICC, on FICS, on other servers and as the startup dialog. That makes 7
> menu items (in addition to items for getting the help, FAQ or README,
> uninstalling). That makes already more than the number of shortcuts I had
> in the WinBoard directory of the installer zip.
>
> I am not pushing for dropping the shortcuts, though; I thought it would be
> a problem where to place them. After all, we decided people would be
> unlikely to use the Windows explorer to navigate to the WinBoard folder,
> as I usually do. And if people are used to the menus from 4.2.7 they would
> be disappointed if 4.4.0 did not have them.
>   

Oh yeah, we'll keep the shortcuts.  I'm just investing how they need to 
be done is all.

> In theory you are right, but this opens upo a can of worms that we better
> not get into (with this version). WinBoard expects the .ini file in its
> installation directory, and seeks it there even if you start it with
> another directory as current directory. It als interprets engine path
> names with respect to this direcdtory (if they do not start with "\").
>
> Changing it is a major break with how things were historically done, and
> will require major rethinking and reprogramming. We will simply have to
> accept that 4.4.0 is not a multi-user program, ...

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.

> > Because of this, it
> > looks like each of these needs its own directory unless we can rename the
> > logo files so they differ.
> >     
>
> I am not sure why you would want the logo files in the same directory.

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.  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.