[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XBoard-devel] links [installer]
Re: [XBoard-devel] links [installer]
Mon, 27 Jul 2009 11:42:24 -0600
Thunderbird 126.96.36.199 (X11/20090608)
Op Ma, 27 juli, 2009 4:45 pm schreef Eric Mullins:
Ok, what does the "@<inifile>" syntax do that's different from "-ini
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.
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
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.