Re: [XBoard-devel] Plans for 4.4.2

[Tim Mann]

HG, I'm with you here.  I think the WinBoard option parsing code can be
generalized and used in XBoard too, since it accepts a Unix-like syntax
as well as the Windows-like syntax.  As you noted, the options that do
front-end stuff are more problematic to unify, since the details there
tend to differ between XBoard and WinBoard.

One point on Xt options: with the port to GTK, there will no longer be
a need to recognize standard Xt command-line options or recognize "X
resources" as alternatives to options -- GTK programs don't do that.
There might be a need to recognize standard GTK command-line options,
though. IIRC, GTK provides a function that you can pass the (argc,
argv) pair to first; it parses out the options that it understands and
removes them, and your code can then parse the rest.  (I think Xt's
option parsing can be used that way too, though currently XBoard has an
Xt routine parse all the options.)

On Tue, 03 Nov 2009 20:08:03 +0100, "h.g. muller" <address@hidden> wrote:
> 
> >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.
> 
> 


-- 
Tim Mann  address@hidden  http://tim-mann.org/