[XBoard-devel] file associations / positional arguments

[h.g. muller]

I had an idea:

Currently WinBoard/XBoard are installed with 3 file-type associations, 
basically through the following commands:
PGN: winboard -ncp -lgf CLICKEDFILE
FEN: winboard -ncp -lpf CLICKEDFILE
TRN: winboard -mm -tf CLICKEDFILE
(in practice I also include an indirection to a settings file, to make it 
easier for users to configure the commands, like @viewer.ini for the PGN.)

It occurred to me that we could also associate it to the file type of 
settings files. The current convention is to name these .INI, but in 
Windows this file type is already heavily overloaded, so we could change it 
to something unique (e.g. WSF for WinBoard Settings File), and give it its 
own icon (also the black Knight, orperhaps a white one?) Clicking such a 
file would then invoke the command
WSF: winboard @CLICKEDFILE

This would make it completely unnecessary to distribute WinBoard with 
shortcuts, as every settings file would automatically behave as a shortcut. 
Currently the installer puts a lot of shortcuts in the WinBoard folder, 
which all take their command-line options from a indirection file. Like 
FICS.lnk being a shortcut with target line "winboard @FICS.ini". A problem, 
however, is that the shortcuts are not "portable": rename the WinBoard 
folder after install, and they cease to work.

Another, related idea:

WinBoard still has the (deprecated?) feature of 'positional arguments', 
where a first argument that is not an option name (i.e. does not start with 
a dash) is taken to be a -loadGameFile.

People that naively make file association between PGN and WinBoard through 
the Windows Properties dialog will stumble onto this, as Windows will 
associate the command "winboard CLICKEDFILE". (User do this, for instance, 
because they use several Chess GUIs, and want to dynamically alter the 
association of PGN to fit what they are using at the moment.) This is not 
really what they intended, and the -ncp option is missing, so that they 
will still get the startup dialog. But if they make the naive association 
with the FEN or TRN type, they not only get to the startup dialog, but 
after they okay it, they run into the error message that the file contains 
no games.

So I am thinking of reviving and revamping this mechansim of positional 
arguments in a slightly more polished way: WinBoard could examine the 
argument it is going to use as filename, to see what extension it has, and 
decide based on that if it is going to treat it as a game, position, 
tournament or settings file. (i.e. imply the options -lgf, -lpf, -tf or @ 
for it). As additional side effect it can set the default mode to -ncp, in 
order to suppress the startup dialog (or -mm for TRN files). The latter 
would be new, and break strict backward compatibility with the use of a 
positional argument for the PGN case. Are here any iportant considerations 
I overlooked, which would make this a bad idea?

Finally:

In the latest XBoard I added a new 'major mode': -viewer. This is a bit of 
a kludgy construct, where there is a string option -viewerOptions, and 
starting in -viewer mode would parse the -viewerOptions string as if it 
were command line. So in a sense -viewer is equivalent to 
@viewerOptions.ini, except that the inserted options are not coming from an 
ini file, but from a string, which itself is a persistent option (and thus 
stored in the main ini file). In a sense this is like adding a "section" to 
the ini file that will only apply in -viewer mode. The reason for doing it 
this way, is that it would be easy for the user to 'edit' the 
viewerOptions, by providing a control for it in a menu dialog. (And this 
would automatically make it a private user option, rather than a global 
setting, so each user could, say, configure his own favorite analysis 
engine in viewer mode, associated with PGN files.) The 
/firstChessProgramNames can actually be considered a precedent of this, 
where each line in it is processed as an command-line option string in case 
the engine is selected from the startup or load engine dialog.

The reason I bring this up here is that it would be even more versatile to 
not force -ncp with a positionally selected PGN file, but in stead force 
-viewer mode. This way a 'naive' association could be made totally 
equivalent to the association "winboard @viewer -lgf CLICKEDFILE" that the 
installer creates now. Of course the @viewer options are no good for a 
tourney file, but a similar options -tourneyOptions could be created, to be 
parsed for a positional TRN argument.

Is this a good idea, or does this just advance us further on the path of 
hideous kludges?

To elaborate on this scheme even more: with -viewer you would force 
WinBoard to insert the -viewerOptions string, but there is no way to force 
insertion of a line in the -firstChessProgramNames list option into the 
command line (other than using the startup-dialog comboboxes). You can 
specify an engine with -fcp, but you would not automatically activate all 
options that were installed with it (if it was installed). So we could 
provide an option -ficp (-firstInstalledChessProgram) that is to -fcp what 
-viewer is to -ncp: -ficp NAME would search the engine (by 'tidy name') in 
the -firstChessProgramNames list, and then insert that entire line 
(prefixed with -fcp) at that point into the command line (like -viewer 
would insert -viewerOptions into the command line).