[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XBoard-devel] Future plans

From: Michel Van den Bergh
Subject: Re: [XBoard-devel] Future plans
Date: Mon, 07 Sep 2009 00:59:30 +0900
User-agent: Thunderbird (X11/20090817)

h.g. muller wrote:
Now 4.4.0 is released, it is a good time to plan the next steps.
I still have some WinBoard patches here that I should merge into the main line,
so they can go into 4.4.1. In particular the chat windows in ICS mode.
I still want to improve those a little as well, so that they can also be used to listen to a specific channel, rather than to persons of a given ICS handle.

I guess the most urgent change that is needed is the way the backend
communicates with Polyglot for starting up UCI engines, namely through
temporary files. This is ugly, and new Polyglots support a method to
avoid it, because they accept the engine name on the command line.
So I want to rip out the stuff handling the polyglot_1st and _2nd files
in response to the -fUCI / -sUCI commands, and replace it by a more
general way of handling adapters: in stead of giving a "polyglotDirectory"
in which XBoard looks for a file called "polyglot.exe", the user should
simply specify an "adapterCommand" in which some meta-characters
could be used to designate engine name, directory etc. Like
"./polyglot -ec %cp -ed %d" Where %cp would be replaced by the value
of -scp or -scp (whichever was applicable, and %d by tht of -fd or -sd, etc.)
I think it would be useful to have a command line option to override the
engine name (myname).
I have seen this requested by people for printing to png files.
But the adapter could also use this to find a particular config file to
implement persistence
(this is how polyglot currently does it).

I promised Guenther Simon I would have a look at implementing another
tag for display in the game list; this should be easy (but requires me
to touch code that I never looked at until now). My guess is that some
re-writing of the wgamelist.c code is needed to seprate off the back-end
part of the features added by Alessandro to this window, so they can
be ported to XBoard more easily.

The Engine-Settings dialog still needs work. Not all option types of the
extended protocol are currently implemented, XBoard does not use
the intermediate-level formatting used in WinBoard, so the dialog looks
very messy there. And WinBoard should pay attention to the length
of the option names to dynamically format the dialog so they remain
fully visible. This is easy, but tedious.

The startup dialog should be abolished, and be reformed to a menu dialog
that can be summoned up at any time. If this turns out to be too difficult,
(It miht interfere with the basic logic of the back-end), at least the
startup dialog shoud be equiped with a check box that would add the
engine that is selected (if it was typed in) to the list shown in the comboboxes (whch are string options saved in the winboard.ini file), and buttons should be provided to delete engines from those lists too. In fact it seems undesirable to have separate lists for first and second engine, so the lists should be shared, while some meta-character used to indicate "first" or "second" in the WB options
given with the engine should make that possible.

I want to rewrite evalgraph.c, to give it good back-end / front-end separation,
so it can be easily ported to XBoard and/or GtkBoard.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]