Question to Windows users

[F. Bluemers]

...
Some users might want a "per instance" ini file,where each winboard would run from its own folder with its own ini file.
Maybe with an option?

In an old program i've done something like this: if there are the ini file in program folder, i load it and use it; if not then i searched the registry. Another solution is simply to add a program parameters in command line, like this:

winboard -useregistry
winboard -useini=somepath/inifile.ini

yes,winboard already has such an option,I should have checked first...

-ini or -settingsFile filename

http://www.gnu.org/software/xboard/manu ... ml#Options

[Gian-Carlo Pascutto]

C:\Documents and Settings\<user>\Application Data\ on XP
C:\Users\<user>\AppData\ on Vista
C:\Documents and Settings\<user>\AppData\Roaming\ on Win7 (it seems)

But I now get complaints that these folders cannot be written without administrator permission. (And it is hidden.)

You'll need to debug this. While it's normal for the folder to be hidden the user absolutely should have access to it. Or provide more details exactly what those users are seeing/reporting.

As far as I know what you're doing is correct.

Is this really unintended use of the AppData folder? Where else would a user expect a settings file for an application he installed? Should the winboard.ini file be better located in his "My Documents" folder?

Yes. Nowhere, unless the application was badly written. *Absolutely not*. (In that order)

[brianr]

Firstly, I would like to say thank you to HGM for his boundless support for Winboard. Moreover, I think the tourney manager feature is great.

Personally, I strongly prefer all Winboard files to be in the directory where I "install" Winboard. If I want multiple versions, I can create them, all with different, easily edited .ini files. Moreover, I don't want any installerl, nor any file types associated with anything, nor any start menu folders or other shortcuts, etc. I can manage all that if and when needed. For example, I use .pgn files with SCID, Arena, Winboard, Bayeselo, Notepad, etc...

Let's be realistic. Winboard is far from a program that an average, non-technical Windows user would ever use on a PC with multiple user accounts. I suspect that the primary Winboard users are engine authors, testers, and other computer chess enthusiasts.

Please, please revert to the earlier, simpler approach and keep all .ini files out of any "my documents" and as far from the Windows registry as possible.

Yes, the current "C:\Documents and Settings\Brian\AppData\Roaming" second winboard.ini file is a "proper Windows" solution, but it addresses a non-problem from my perspective. Administrator rights are needed to even get to it.

I just counted 16 separate .ini files. One could just use the traditional winboard.ini file in Winboard's own directory. Then create a separate "volatile.ini" file for the appropriate options in the same place. Each of these two files would have mostly the same set of sections to consolidate/replace the numerous separate .ini files now used.

[rreagan]

What would be the best place in modern Windows systems to store the user settings file of a GUI? For WinBoard I so far always used the user's Application Data directory:

C:\Documents and Settings\<user>\Application Data\ on XP
C:\Users\<user>\AppData\ on Vista
C:\Documents and Settings\<user>\AppData\Roaming\ on Win7 (it seems)

But I now get complaints that these folders cannot be written without administrator permission. (And it is hidden.)

Is this really unintended use of the AppData folder? Where else would a user expect a settings file for an application he installed? Should the winboard.ini file be better located in his "My Documents" folder?

On Windows 7, assuming a default installation on C:, %appdata% will expand to C:\Users\<user>\AppData\Roaming. Technically this is for "roaming profiles", which is probably not what you want. It's better to use %localappdata% which will expand to C:\Users\<user>\AppData\Local.

Google Chrome has an installer that does not require admin rights. It installs the entire application to AppData\Local.

UAC (User Access Control) may further complicate the matter on Windows 7, but generally speaking you should be able to access AppData\Local or AppData\Roaming without requiring admin rights.

Also, on Windows 7, "C:\Documents and Settings" is, I believe, a junction (symbolic link) to C:\Users. So if you write to "C:\Documents and Settings\<user>\AppData\Roaming", you are really writing to C:\Users\<user>\AppData\Roaming. However, if you try to browse to "C:\Documents and Settings" you will get "Access Denied". So be sure you are using the environment variables like %localappdata% or %appdata%.

If you are getting access denied, try running Process Monitor to see what the process is trying to access. It may be doing something unexpected under the hood. When you start it, it will spew events in the log window. Go to the File menu and uncheck Capture Events (or press CTRL+E). Then
go to Filter menu, select "Drop Filtered Events", and then Filter menu, select Filter. There you can filter by your Process name (the .exe name). Otherwise it will spew events for the whole system. Once you filter to your process name it will show you all events involving files, registry, and network. It will tell you the path, and the result (success, access denied, etc).

Process Monitor
http://technet.microsoft.com/en-us/sysi ... 96645.aspx

It's also possible that if this problem is only happening to one specific person and you can't reproduce it, that person may be infected with some kind of malware, or they may have some draconian antivirus software that takes over their computer (Norton, etc).

[hgm]

Personally, I strongly prefer all Winboard files to be in the directory where I "install" Winboard. If I want multiple versions, I can create them, all with different, easily edited .ini files. Moreover, I don't want any installerl, nor any file types associated with anything, nor any start menu folders or other shortcuts, etc. I can manage all that if and when needed. For example, I use .pgn files with SCID, Arena, Winboard, Bayeselo, Notepad, etc...

Well, most users do want start-menu items, and it is difficult to please everyone. It should be posible to offer a 'portable release' next to the installer, though. This could nearly contain everything (Polyglot and other adapters, engines) that the installer package contains, and thus would still be very much more elaborate than a 'bare-bones' package containing only winboard.exe + winboard.ini.

But the design of the tournament manager is really such that it is no good without associating TRN files with the command winboard.exe @tourney -tf %1, or at least winboard.exe -mm -tf %1, to start WinBoard in tourney mode when you double-click such a file. I am surprised you like the tourney manager even without that working, because I would think it sucked if I could not do that! Portable installs are not supposed to make such associations.

Perhaps a Windows expert can help us here: is it possible to make file associations 'by hand' (e.g. using the properties menu), which have a non-trivial command line (which contains all kind of command-line options next to the application filename and document filename)?

Let's be realistic. Winboard is far from a program that an average, non-technical Windows user would ever use on a PC with multiple user accounts. I suspect that the primary Winboard users are engine authors, testers, and other computer chess enthusiasts.

Actually most users are FICS players, without any technical background whatsoever. I have no statistics on this, but having more persons in one family, sharing one computer and each using FICS does not seem that far-fetched a scenario. Many schools install WinBoard on the school computer, and the pupils will have different accounts.

Please, please revert to the earlier, simpler approach and keep all .ini files out of any "my documents" and as far from the Windows registry as possible.

For technical people that want this, it should not be too difficult to configure it themselves. The master ini file still is in the WinBoard folder, as always. It is this master ini file that the saving is redirected to the user's AppData folder, by the options it contains at the end:

/settingsFile=%APPDATA%\winboard.ini
/saveSettingsFile=%APPDATA%\winboard.ini

If you delete those two lines, WinBoard would save the settings to the winboard.ini in its own folder, as always, overwriting the installed winboard.ini. This is not recommended, however, as it destroys the master / slave structure of the settings files, and thus removes the possibility to alter defaults of volatile options (which do not survive whe the slave settings file is overwritten on the next saving of settings). It is better to change the lines to

/settingsFile=setting.ini
/saveSettingsFile=settings.ini

upon which you would have the user settings be saved in settings.ini in the WinBoard folder, and the winboard.ini remains available as master settings file, where you can safely specify volatile options.

I just counted 16 separate .ini files. One could just use the traditional winboard.ini file in Winboard's own directory. Then create a separate "volatile.ini" file for the appropriate options in the same place. Each of these two files would have mostly the same set of sections to consolidate/replace the numerous separate .ini files now used.

Your proposed volatile.ini seems to coincide with what I called settings.ini above. As I showed there, this is no property of WinBoard, but merely of the configuration, and editing the winboard.ini can achieve this. I am not sure which other ini files you refer to. Are these all winboard.ini? If you mean files like viewer.ini, tourney.ini, ICSbot.ini, FICS.ini... These are not used for saving settings, but are merely used to collect the options used in the various shortcuts (and menu items, which technically are shortcuts in the menu folder) that are supplied with the install. They contain the command-line options that logically should have been in the 'target' line of the shortcut (as the Properties dialog calls the command line). The target lines have a length limit, however, so that the required options won't fit there. In addition, most people would not be able to find their menu shortcuts to alter the command line in those. Finally, the command lines needed for file associations are not even shortcuts, but hidden in the registry. So to give the users an easy to access, easy to change method for configuring these shortcuts / menu items / associations, the options used by those are collected in editable ini files in the WinBoard folder.

Note that also in these 'shortcut ini files' saving and reloading of the settings can be specified. In the latest release I used this in the FICS and ICC menu items to give them a user settings file (winboard_ics.ini in AppData) that is different from the user settings file that would be normally used (e.g. when starting from the startup dialog). This because the optimal configuration for ICS use is often very different from that for other uses (other windows open, other screen layout, board size). By employing a separate user settings file, the settings for the two tasks will never mix.

[brianr]

Once again you are right. The better approach is to keep it simple and let some users that want to do their own customizations.
And, thanks for your additional information and perspective on a user class that would never have occured to me (schools!).

While the default is keeping things simple for per-user installations, there are already enough options for some of us to customize things.
For example, as you have suggested (twice now, including your email):

But the design of the tournament manager is really such that it is no good without associating TRN files with the command winboard.exe @tourney -tf %1, or at least winboard.exe -mm -tf %1, to start WinBoard in tourney mode when you double-click such a file. I am surprised you like the tourney manager even without that working, because I would think it sucked if I could not do that! Portable installs are not supposed to make such associations.

I have easily done that and associated .trn with winboard.exe @tourney -tf %1 and it works fine.

That said, since Winboard has grown to become many things for many users beyond a "simple" GUI for backend engines (engine/engine games, UCI support, book support, tournaments, chess servers, variants, eval graphs, seek map, kibs, etc), just one observation at this point: I was under the impression that a major top-level design goal was the convergence of Winboard and Xboard.

So, just curious, but how does Xboard handle this area?

Incidentally, from a Windows environment point of view, the collection of .ini files are not the documents of Winboard, but the .pgn and .trn files are I would think.

[hgm]

Once again you are right. The better approach is to keep it simple and let some users that want to do their own customizations.
And, thanks for your additional information and perspective on a user class that would never have occurred to me (schools!).

Indeed. I would not have thought of that myself, were it not that the first request that I received for a configuration where the WinBoard folder would only be writable for administrator had not come from a school. And I am currently involved in setting up an ICS for a school in Puerto Rico, for which I also supply a dedicated WinBoard package.

I have easily done that and associated .trn with winboard.exe @tourney -tf %1 and it works fine.

Please tell me how you do that! It occurred to me that it would be possible to revive the deprecated 'positional arguments', which are now always interpreted as game files, to distinguish the files by extension. And then treat FEN and EPD files as -lpf arguments, while a TRN file could be considered a -tf argument, and at the same time force the -mm option (and perhaps -ncp). It wouldn't be as versatile as processing options from a tourney.ini file, but at least it would work.

I was under the impression that a major top-level design goal was the convergence of Winboard and Xboard.

So, just curious, but how does Xboard handle this area?

I am happy to say that this goal has been almost completely achieved. Except for a few details, XBoard is fully equivalent to WinBoard. Remaining differences are that XBoard cannot be resized during a session (i.e. the square size is constant), and that XBoard uses the terminal window from which it was launched as ICS console. With as a consequence that things like the ICS context menu cannot be implemented, as XBoard cannot catch the mouse clicks on another application. Attempts to present ICS output in a dialog window spawned by XBoard have stranded on the problem that the Athena widget set used by XBoard does not allow line-by-line colorization. XBoard does have a static ICS menu non-modal dialog, which can be configured by the user to emit ICS commands at the press of a button to soften this a bit.

For storing settings XBoard also uses the master-user approach. On Linux binaries are by convention not stored in the same directory as their data files, as is Windows custom, but go all together in directories like /usr/bin or /usr/games, which then are in the shell path. They must know where to find their data files, and for XBoard these are in /usr/share/games/xboard. (For instance board-texture pixmaps, and bitmaps for monochrome pieces.) Settings files by convention are in /etc, so the master settings file comparable to the winboard.ini in the WinBoard folder is /etc/xboard/xboard.conf. This file redirects the saving of settings to ~/.xboardrc, where ~ stands for the user's home directory. Linux users are much more focused on their home directory as Windows users on their My Documents, because they don't have permission to create or write files anywhere else.

Of course none of this is really hard coded, as the file-system conventions for Linux vary even more between distributions than they do between different Windows versions. So the autoconf process makes use of meta symbols like $CONFDIR$, $DATADIR$ etc.

Incidentally, from a Windows environment point of view, the collection of .ini files are not the documents of Winboard, but the .pgn and .trn files are I would think.

This is a natural thought, but it is not unusual for an application to use many different document formats, some used less frequently then their main document type (templates, style files, project files). By stretching the definition of 'document' a little, one could argue the contents of which is of interest to a user, and which he might want to edit, should be considered a document.

If the ini type was not already so overloaded, it would perhaps not have been a crazy idea to also associate these with WinBoard. So that double-clicking them would invoke WinBoard through the command

winboard.exe @CLICKEDFILE

This would safe the user the trouble of creating Windows shortcuts: each ini file would automatically become a shortcut, launching WinBoard according to the options specified in it. It might even be worth to define a new, more unique extension for this (e.g. WSF, for WinBoard Settings File), which then could get its own icon (a variation on the black Knight).

[brianr]

I have easily done that and associated .trn with winboard.exe @tourney -tf %1 and it works fine.

[Please tell me how you do that! It occurred to me that it would be possible to revive the deprecated 'positional arguments', which are now always interpreted as game files, to distinguish the files by extension. And then treat FEN and EPD files as -lpf arguments, while a TRN file could be considered a -tf argument, and at the same time force the -mm option (and perhaps -ncp). It wouldn't be as versatile as processing options from a tourney.ini file, but at least it would work.

Just run cmd with administrator rights and do this:

Code: Select all

C:\Windows\system32>assoc .trn=tourney
.trn=tourney

C:\Windows\system32>ftype tourney=C:\WinBoard-4.6.2\WinBoard\winboard.exe @tourney -tf %1
tourney=C:\WinBoard-4.6.2\WinBoard\winboard.exe @tourney -tf %1

C:\Windows\system32>

I have not bothered to look for the Windows environment variables to not have to hard code the windboard.exe file location.
But, if/when I get a new Winboard version I can just update it then anyway.

Note that this will not work if .trn has already been associated with a program at the higher system level (like Notepad for .txt).
In that case, under Win7 it seems rather difficult to remove the assocation without directly editing the registry, which I try to avoid.
Instead, just use a handly little util like Unassoc
http://www.winhelponline.com/blog/unass ... s-7-vista/

[hgm]

I don't get it:

I have renamed an ini file to give it a new extension .xsf. Now I want to have WinBoard open it, by right-clicking it, and select from the context menu "Open with..." (and then create an association by ticking "Always open this type of document with this application").

Problem is that WinBoard is not in the list of programs that is offred. This should not be a problem, because there is a "Browse" button suplied, which I can use to browse to winboard.exe, and select it.

But after this, WinBoard does not appear anywhere amongst the possible choices, and OK'ing the dialogs insist that the document is now associated to 7zip!

What am I doing wrong? Why does "Open with" resists using WinBoard?

[brianr]

There are multiple levels of extension association. Using the "assoc" and "ftype" example above, Winboard is now one of the options with right click. The "browse" and "always open with" approach did not work for me either. It could be the path to Winboard. You could try putting a copy of Winboard in the same system program directory as notepad.exe like %windir%\system32\notepad.exe, and that might work too.