20 Jan 2010 10:43
Re: gtk version status
h.g. muller <h.g.muller <at> hccnet.nl>
2010-01-20 09:43:52 GMT
2010-01-20 09:43:52 GMT
>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(¶m, value)'; and 'State(¶m);' 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.