Re: [XBoard-devel] Plans for 4.4.2

[h.g. muller]

OK, I see now what the main problem is:

The list of options in WinBoard contains not only pointers to
appData fields (for back-end options), but also many pointers
directly to front-end variables. In particular there are lots of
window-coordinate options, and even in WinBoard there are
two different systems for storing them: an obsolete way as
simple variables, e.g. commentX, commentY, commentW,
commentH, or a modern way, which can be subject to
the -stickyWindows option (I guess this is called "docking"),
where they are stored in fields of a WindowPlacement struct.

A lot of code in the SaveSettings routine is dedicated to
obtaining the window coordinates, i.e. very front-end, and
becase of the different systems in use it is difficult to move
that code to the front-ed as a callable function.

Of course it would be possible to split the option list in a
front-end and a back-end part, and let ParseArgs work on
both parts separately, while spliting SaveSettings in two
parts as well. In the end we will want similar front-end
options in XBoard and WinBoard, though, in particular all
the window coordinates.

I guess the best approach would be to first do a lot of code
refactoring in winboard.c, to get better front-end and
back-end separation of the option handling. In particular,
all windows should be adressible through a #defined
(in common.h?) numeric ID which is kown to the back-end,
and all platform-ependent handles to the windows (which now
are simple variables with names like HWND engineOutputDialog
in WinBoard and Widget engineOutputShell in Xboard)
should then be grouped into an array indexed by this ID.
All simple coordinate variables should then be grouped
in a corresponding (back-end) array of WindowPlacement structs.
The only front-end part would then be a routine that fills
the WindowPlacement struct of a window with given ID,
and the rest could all be back-end.

Another problem area seems to be the handling of fonts.