Re: [XBoard-devel] Plans for 4.4.2

[h.g. muller]

> I think we do have that freedom. Winboard and Xboard have different
> formats at the moment as you say, so one of them needs to change in the
> near future anyway. Why not change both and then use a format that is
> also used by other programs and comes with a nice library?

The XBoard command-line style of XBoard is understood by WinBoard,
and in fact used by many WinBoard users. Despite the fact that WinBoard
itself uses a different (MS-DOS-style) format in the winboard.ini file.
I don't know how many option names are different, but most standard
options (-fcp -scp -fd -sd -ics -icshost) are alf the same. Perhaps front-end
options specifying fonts and colors are different, I never checked that.
But there is no need at all to do a drastic format change. I think we should
simply both understand the both - and / as option flag, and ehite space, = 
and :
as separater between name and value. As XBoard does not have an ini file
at all, currently, it would be logical to save in the format of WinBoard.
There is really no need to break anything. If some front-end options will have
to change, that will likely be a natural consequence of the front end
being different, and offering different features. (E.g. no discrete square 
sizes,
but continuous scaling).

> If we ever want to change those things I think doing so when changing
> from 4.x to 5.x would be the opportunity.
>
> As for old scripts, we could include a parser that either pops up an
> error message, saying that the format is outdated and that you now need
> to use XYZ instead or even have a 5.0.x still understand both old
> windows and xboard syntax and drop that only in 5.1.x.
>
> As for ini-files my preference would be an options --ini-file or
> something like that. At least on unix I have never seen the @ symbol
> used for something like this.

Well, @ is a kind of universal symbol for indirection. And I certainly
would not prefer a word of 11 characters over a single keystroke.

> that is the goal of the gtk version after all... having only one version
> and not two anymore...

Indeed, having a unified source would solve this. This is why I originally
listed it amongst the XBoard features to be postponed to 5.0.
But we will still have to port all the functionality that WinBoard offers now
and has options for to XBoard. So I think it will still be important to
move as much as possible of the current WinBoard front-end to the
back-end. There is no reason for the saving of options to a file should
reside in the front-end; in the end we only save platform-independent
quantities. If the SaveSettings code refers Micro-Soft data-types,
it is just poorly designed. I some option values are inherently platform
dependent (e.g fonts, beause the have different attributes and attribute
names), then the parsing of such data-types shuld stay in the front-end,
but in general we just store integers and strings.