Op Wo, 27 februari, 2013 7:55 pm schreef Arun Persaud: >> This does seem a pretty serious bug (for those that have X-servers that >> have this bug). Does it warrant quick release of a 4.7.1? Or should we >> perhaps wait until all translations are in, and do a 4.7.1 then? Or >> perhaps try to do some more fixing of the GTK build on the side? > > Up to you. I could wait a bit with 4.7.1 and wouldn't mind getting some > more new features in at the same time.
Well, I guess that the need for a 4.7.1 has increased a little, as someone reported a bug in the Analyze Game function batch mode. It turns out this mode in general does not save the games it annotates, which was the sole reason for its existence. I missed that when testing, because the saving is dependent on the presence of a 'result comment', and I had only been analyzing games where the analyzing engine could see the game had finished (mate or 3-fold rep), and would provide the applicable result comment. But on human games, which in general end in resign or draw by agreement, it never saved them. In addition there were a few annoying incompatibilities between the WB protocol extensions used in the Alien Edition, and standard WB protocol used in 4.7.0, making it impossible to run engines designed for the Alien Edition to fully work under regular WinBoard even in variants the latter did support. Although not strictly a bug, it seemed better to fix that as well. What 'new features' did you have in mind? Normally we would not do any bigger things within a stable branch, out of fear of jeopardizing the stability. I have some ideas, but they are mostly major stuff: *) Rework the back-end code, to make tests on variant disappear in favor of tests on individual game characteristics (e.g. not test for shatranj, but test general-purpose rule flags that tell whether double Pawn pushing is allowed or all promotions are to Ferz, etc.). This to make it easier for engines to tailor the behavior of the GUI to the need of non-standard variants. *) Port the 'highlight feature' from the Alien Edition to the regular version (and to XBoard). This feature allows the engine to perform the 'show target squares' function, which XBoard cannot do if legality testing is off, and pieces might not move as XBoard thinks they do. A protocol extension informs the engine when the user grabs or releases pieces, and the engine can reply with a highlight command containing a 'color-FEN' to indicate where marker dots should appear. This also makes it possible to do legality testing in the GUI for games with unknown rules: it can only accept releases of the piece on the squaes the engine marked. This can be elaborated on by assigning different functions to different color that XBoard will be aware of: squares the 'lifted' piece could promote on can be marked with a special 'promotion color', and when the user puts down the piece on such a square, this could be a reason for XBoard to show the promotion popup (or activate sweep selection of the promotion piece), even if the square would not ly in what it normally thinks is the promotion zone. *) Allow the use of a referee engine, possibly connected as third engine. With legality testing off WinBoard would rely on this referee engine for determining move legality and result-claims. *) A somewhat more modest feature would be to improve the Eval Graph. Some people like to have a derivative-mode there, where it does not show the absolute score, but the amount that the score changed by the previous move (so that blunders show up as spikes). This could be provided as an alternative view. (Not sure what would be the best method for the user to switch views, though. A right-click?) The Eval Graph also has a 'zoom' function, expanding the score range [-1, 1], which can be set in some dialog (and for WinBoard, only through a command-line option). Perhaps the mouse wheel could be used to modify this zoom factor when the pointer is in the Eval Graph window. *) Finally we could do themes for XBoard. WinBoard now has a Themes dialog that people seem to like; it stores the theme settings in the settings file in a way similar to the list of installed engines, and allows the user to define his own themes. It would be trivial to port this dialog and treatment of themes to XBoard.
