Re: [XBoard-devel] Plans for 4.4.2

[h.g. muller]

> since I'm not that familiar with that syntax I can't really say much...
> I think though that in the long run having a common syntax file via e.g.
> GKeyfiles that is also used by other programs might be an advantage.
> Since GKeyfiles looks apperently a lot like ini-files, is that similar
> to what Winboard is using anyway at the moment?
>
> As long as the command line options goes, I'm also not familiar with the
> winboard one, but I do like getopt ;) and am used to "-" for short
> options and "--" for long options, but I have no idea if this is the
> same on windows...

The command-line and the file format are the same in WinBoard,
so the same parser can be used for both of them. Except that in the file
there is one option per line, which the parser does not care about because
it parses any LF as white space. WB is a bit flexible in its option format.
It understands the XBoard commandline format:

-optionName VALUE

but in considers  leading '/' as equivalent to '-', while the optionName can
also be separated from the VALUE by '=' or ':'. So the common Windows
'styles' for options,

/optionName=VALUE
/optionName:VALUE

are also understood, plus any mixture such as

-optionName=VALUE
/optionName VALUE

For saving it of course has to choose, and it savs as /optionName=VALUE.

I don't think we have the freedom to change how the command-line should
look. Because XBoard does not support a settings file, almost everyone
runs it through very elaborate scripts. These scripts must remain valid.

A complication in XBoard is that the shell treats the command-line first,
before handing it to XBoard. So unlike WinBoard, to XBoard the
command line will look different from the settings file, if they look
the same to the user. Another complication is that (as I understood it)
XBoard also understands general X-toolkit options, which are not defined
in our source code. So what is a fatal error in WinBoard (the parser
encountering an option that is not in the list) must set aside the
option in a separate list for later parsing by Xt. Or perhaps the other
way around; I am not sure how smart Xt is.

Note that current XBoard already parses settings files, when they are
given as @FILENAME on the command line. It is just that there is
o default file that it always parses, and that it does not save settings
on such a file. The format of these files is different from the WB format,
though, and differet from the user command line:
it puts -optionName and VALUE on separate lines. It is basically a dump
of the argv[] array. It would be quite easy to dump the settings this way,
but I don't really like the format. I think -optionName and VALUE should
really go on the same line.

It would be very convenient if WinBoard and XBoard would share the
list of option definitions; it is a constant pain that they currently do not,
and every new option has to be added in duplicate. This is a matter that
is in principle independent of what the parse / save format will be. But
having an existing package (such as Xt) recognize the list puts an extra
requirement on it that makes it hard to put additional information in the
list. (Like which options should be saved in the settings file, and which
not.)

I wil try the following (which should be a small job): extract the ParseArgs
code, SaveSettings code and option-definition list from winboard.c,
and put it in a file args.c. I will then add in xboard.c a routine to convert
an argc, argv-style list back into a single line, delete all the 
option-definition
lists from xboard.c, and let it call the args.c code in stead. We can then see
if there are any unexpected problems.