Re: [XBoard-devel] Future plans

[h.g. muller]

> this should perhaps just go into the gtk-version?

It might indeed be a good idea to leave the really low-level formatting to gtk,
as it is my expectation it will be far easier there than in Windows API.
I still would have to do something about the intermediate-level formatting,
though, (which is back-end), because it does not support all option types
yet. (-string and -path are treated as -file, -slider as -spin, and -reset 
is not
implemented at all.) One problem is that although the intermediate-level
formatting is back-end, it is by-passed by XBoard, which does a more
primitive version of it in its front-end. It will does not be possible to make
XBoard use this part of the back-end without partly re-writing its front-end
for this dialog. So we should perhaps not attempt to touch it at all in
XBoard.

> can this be just part of a preference window, perhaps a 
> preference->startup tab or something like that? Should perhaps also go 
> into the gtk-version...

I am not sure what a preference window is, but what I would like is
that WinBoard would by default start in -ncp mode, and that you could
then load one, two or three engines later from the menus. And also
unload them, and then reload another engine.

> For 4.4.1 separating frontend/backend stuff sounds like a good goal.
>
> Another thing I would like to do is clean up the code a bit more,:
> * get rid of code that's between #if 0 #endif, #ifdef NOTDEF-blocks, #if JAIL
> * there is also #ifdef Gothic, #ifdef Falcon: shouldn't we always include 
> these?
> * would be nice to add more comments to the code ;)
> * remove unused variables, etc.

I left in a lot of stuff to document what I changed, to be able to get back 
when
it did not pan out. I guess that by now we can consider most of the code 
"proven",
and can delete that stuff. The #if JAIL stuff seems a leftover from an 
earlier aborted
attempt to implement holdings in XBoard, which I was not aware of when I
independently implemented them in WinBoard in a completely different way.

What is even more important in terms of cleanup is sensible use of the 
header files.
This currently seems a bit haphazard. Some variables shared by several source
files do not appear in any header file, and are just defined as extern in a 
file
that needed to access variables that before were local to another file. Both
Alessandro and I have been very lazy in this respect, but if there is no clear
philosophy of which headers are shared by which files, it slows you down 
terribly
when you have to figure it out. So either the solution was taken to include an
entire header file that happened to contain one variable that needed to be 
referenced,
rather than moving that variable to a more applicable header, (so that 
after some time
every header is petty much incuded by every .c file) or simply re-declaring 
the variable
as external.

> I would leave all the frontend stuff for the gtk-version.

I will ty to do that as much as possible. But some of the WinBoard patches 
I already
have (the chat windows) are partly front-end. Note that my principal drive 
to add
features is often not to develop the code, but simply because I need that 
functionality,
and need it now (such as the chats for the WCRCC). I am a user more than a 
designer...