[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XBoard-devel] links [installer]

From: Eric Mullins
Subject: Re: [XBoard-devel] links [installer]
Date: Mon, 27 Jul 2009 11:42:24 -0600
User-agent: Thunderbird (X11/20090608)

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.

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]