Re: [XBoard-devel] gtk version status

[h.g. muller]

> yes, btw since we now keep track of castling do we need a button for
> that one too?

Good point. Currently rights are assumed on basis of the pieces being
in their opening location, when you leave the Edit Position menu.
I guess we still want to do that for backward compatibility, but it makes
sense to allow the user to overrule the default assignment. This would
require the back-end to keep track of the rights assignment of every piece
on the back-rank. I guess it would be easiest if it organized that per square;
each time the square gets empty it loses rights, each time you put something
on it it gets default rights (i.e.. Rooks in corners and King on 
right-central file
get rights, others not.) EditPositionDone() would then just collect the rights
from these arrays, rather than assign them by itself. On entering Edit Position
the assignments should be made based on what the position had you are
now editing, so EditPositionEvent() would have to start initializing these
back-rank rights tables.

The piece-menu popup should then have two extra buttons:
"Grant Rights" and "Revoke Rights". When you right-click a back-rank piece,
and use those buttons on it, it would set the rights accordingly. The same
buttons could be used to assign e.p. rights to a pawn, by clicking the e.p. 
square.

This would require the enum type ChessSquare to be expanded with codes
GrantRights and RevokeRights, so they can be passed by the dialog
to EditPositionMenuEvent() to indicate that the buttons were pressed.

> I'll just go ahead and try to set something like this up... I think it
> should be relatively easy to rearrange things later in gtk, since I'm
> using a glade (a graphical interface to design the user interface), so
> it's probably best to just get something working and then perhaps
> improve it later...

OK, one thought: many of the items in the options menu only adjust
variables (mostly in appData, so they could also be set by command-line
options) that affect the behavior of XBoard, either front end (e.g. animate
moves) or back-end (e.g. always promote to queen). Those are trivially
handled when you "flush" the dialog by pressing 'OK'. XBoard no defines
'Procs' for each of those, because it uses simple menu objects to
invoke them, so that it even has to keep track if they are on or off
and check-mark them accordingly. I suppose that when they all go to
a separate dialog, which is not a menu but a collection of checkbox
controls (like in WinBoard), all that gets grouped in the popup and
OK call-back for the dialog: on popup you have to tell which boxes
are checked, and on OK you read out the checked status of all boxes
to copy it back to the corresponding variables. The checking / unchecking
(or text in text edits, etc.) is kept track of by the system as long as the
dialog stays open. (Not sure what using tabs does, though; never used it.)

Some options need immediate action, though, in addition to changing the
option value. E.g. flipView should re-draw the board, ponderNextMove
should send a 'hard' or 'easy' command to the engine, etc. Those are the
more tricky options, and in fact it is very inconvenient that the front-end
has to concern itself with making the distinction.

Perhaps we could mae front-end life easier by introducing two generic calls,
'Alter(&param, value)'; and 'State(&param);' that it could use to let the
back-end handle everything? (Perhaps different calls for int / Boolean and
char* params.) Then the front-end would never have to do more than
interrogate the back-end for the current state of the parameters for which it
has controls thrrough a number of State calls, and on OK copy back
the altered results using a number of Alter calls. The back-end would
have generic handling code to default Alter to a no-op when the value
to be written is the same as that already applied, and copy the new
value otherwise. And it would have a big switch statement to pick
out any parameters that need special handling, such as 'hide thinking',
which might require sending 'post' / 'nopost' to the engine, a whole group
of color settings that would each require re-drawing of the board, etc.

This would also allow a more rational division of labor: You could concern
yourself with designing the gtk dialogs, without having to worry what effects
the controls should have, while I could implement the Alter function
entirely in the backend, using the WinBoard and XBoard front-ends
to test it. In fact, you could already implement the dialogs when we
would supply dummy routines Alter() and State() in the back-end.

I guess I could even have these routines figure out what the type of
the option is, by looking it up in the list of options in args.h, so that
the front-end does not have to worry if the type is Boolean or int.