[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XBoard-devel] Future plans
Re: [XBoard-devel] Future plans
Sun, 06 Sep 2009 20:18:01 +0200
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
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
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
* 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
it did not pan out. I guess that by now we can consider most of the code
and can delete that stuff. The #if JAIL stuff seems a leftover from an
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
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
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
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
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
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
have (the chat windows) are partly front-end. Note that my principal drive
features is often not to develop the code, but simply because I need that
and need it now (such as the chats for the WCRCC). I am a user more than a