Excluding moves from an analysisSome engines allow the user to restrict the moves searched in the root position to a subset of all legal moves. XBoard now provides an interface for the user to indicate which moves should be excluded. The method used is to enter the move starting with a double-click on the piece. So either double-click from-square, and then click to-square, or grab the piece with a double-click, and then drag it to the to-square before you release for the second time. In the latter case there will be an visual cue to remind you that you are not really making the move, namely that the piece you start dragging will also remain on the from-square. The first time you make a move that way in analysis mode, it will be excluded from the analysis of the current position. A new command had to be added to WB protocol to make this possible, and that command ("exclude MOVE") will be sent to the engine. The move will be highlighted in premove highlight colors (normally red). When you enter an excluded move in the double-click way again, its exclusion is cancelled (through sending "include MOVE" to the engine), and the move will remain highlighted in the normal highlight color (yellow). You can currently also exclude all moves but the best at once by double-click dragging a piece (vertically) off board. This is not likely to stay; the final version of this feature will probaly provide another method for this. |
|
|
The exclude header always also contains the items 'none', and 'best', which you can right-click to completely reset the exclusion list, or exclude the current best move (i.e. the first move of the latest reported PV), respectively. Finally, a pseudo-move 'tail', representing all moves not listed explicitly in the header, is always shown as well. It excludes or includes all these remaining moves. a special case is when clicking it would result in no moves being included at all; in that case the current best move will remain included.
|
A new WB protocol command "setscore SCORE DEPTH" has been defined, which can be used to set the score an engine should use for a given position by hand. Currently XBoard does not use this yet, but the intention is to allow the user to use the Adjudicate items in the Action menu to define the current position as a win, loss or draw.
Like WinBoard, XBoard now also has the possibility to display player logos next to the clocks. To enable this feature, an option -logoSize was added to XBoard. This specifies the width (in pixels) of the logo pixmaps. (The height is always assumed to be half the width.) When the value of this option differs from the default 0, and is not more than 1/4 of the board width, XBoard creates space for the logos, by displaying the clocks as two lines. Commonly used logo sizes are 100 x 50 or 130 x 65.
|
Like in WinBoard, a new boolean option -autoLogo causes XBoard to automatically look for logos corresponding to the playing engine, human player, or the ICS to which you are connected. Unlike WinBoard, you can specify a directory where XBoard looks for the logos, with the new -logoDir option. All these options are persistent. The name of the logo files must be the 'tidy name' of the engine (also used as mnemonic in the Load Engine dialog), or the domain name of the ICS, or user name of the human, suffixed by .xpm, for XBoard to recognize them under -autoLogo. The logos can also be specified explicitly (overruling the -autoLogo choice), with the volatile options -firstLogo, -secondLogo. |
|
XBoard now has chat facilities a bit similar to WinBoard's chat boxes. Only difference is that there is only a single window to contain all chats (upto 5), which cannot be 'unstacked' to see the chats side by side. You can only see the 'foreground chat', with the person (or channel) that is written in the chat-partner field at the upper left. The other chats are only represented by buttons in the top row. If there are messages in those chats you have not seen yet, the corresponding button turns orange.
|
Clicking a button moves the handle (or channel) it mentioned to the chat-partner field, so that the corresponding chat becomes foreground, and rearranges the buttons. You can then type to that person or channel (or shout, or whisper) without having to prefix the messages with 'tell ...', 'shout' or whatever. XBoard will do this for you, depending on what is in the chat-partner field. At any time you can change the content of that field (terminated by <Enter>!), to change with who you are chatting. This is also the way to create new, simultaneous chats: initially all buttons are blank; just select one (so the chat-partner field gets cleared, and the old partner moves to one of the buttons), type a new handle there, and you can chat to that person. |
Now that the 4.6.x branch has been launched, and will see a feature freeze, it is a good time for large scale reorganization and clean-up of the code. This is now going on in the 'refactor' branch of the repository on this website. A first goal was to split up the code base in more files, because some of the files are getting unwieldly large and hard to handle.
The fist effort in this direction focuses on the X11 front-end of XBoard. A second important incentive for splitting up the large xboard.c is to get better separation of true (X11-dependent) front-end code from platform-independent 'business logic', which could be back-end (although it is not shared with WinBoard). The amount of X11 code, which in the past has been replicated out of control through clone-mutate addition of new features, can be greatly reduced by merging code sections that do nearly the same, the differences being taken care of by a small amount of interspersed conditional code.
Along that road, a lot of the existing X11 code in xboard.c has been made generally useful, and relocated into the generic dialog creator in xoptions.c. As a consequence, all visible windows of XBoard, including the main window, (including pull-down and popup menus), are now generated by the generic popup (which formerly only did menu dialog). The tables describing how the windows have to look are completely X11 independent, and have been split off from the xoptions.c file to a new file dialogs.c. All X11-independent stuff about menus (menu description and enable tables) has been moved to a file menus.c. Finally, there was a lot of X11-independent, but Unix specific code (for handling creation of engine processes, communicating with thm through pipes, etc.). This has all been moved to a new file system.c.
A lot of X11-independent 'busines logic' could also be combed out of the code for drawing the board and animating the moves. This code now has all been moved to a file board.c. It draws on the basic primitive to draw one square with a requested piece, square color, marker dot and inscription (board coordinate or crazyhouse holdings count). In addition there are some simple primitives for drawing square-border highlights, the line grid and the highlight arrow.
Listboxes in XBoard dialogsThere were two XBoard dialogs that used listboxes: the game-list window, and the game-list options dialog. The first of those was more complex, because it could grow very big, and was thus mounted inside a 'viewport', enabling the user to scroll through it. The code for viewport + listbox has now been incorporated into the generic popup, by creation of a new option type 'ListBox'. As a result, these windows can now be generated by this dialog creator too, meaning that they can also draw on all features this creator already supported. But, even more importantly, it makes it trivial for other dialogs to use listboxes as well. The code has been a bit augmented as well: a callback has been added to allow vertical scrolling of such generically generated listboxes with the mouse wheel. This scrolling can also be activated from the code, which is now used in the game list to always keep the selected item in view. |
|
There are three ways to select a subset from the game list: you can filter on a substring of the header lines (e.g. a player name), set thresholds for Elo and date in the Load Game dialog, or select on a position occurring in the game. All three methods can be used simultaneously. But sometimes you might want to select based on two positions. This can now be done with the new 'narrow' button in the game list: unlike 'find position', which starts a search with a clean slate (taking text and Elo/date filters into account), this only selects from games that were already selected in the list. This way you can select for position after position, e.g. games that started with 1.e4 (using 'exact match'), where white castled Q-side (in 'subset mode' with only Kc1 and Rd1 on the board), black castled K-side (again subset mode, with Kg8, Rf8 on an otherwise bare board), and ended in a Rook ending (in 'material range' mode with KRKR on the lower board half, and all Pawns on the upper board half). After using 'narrow' three times (after the initial 'fiind position', you are left with only the games that satisfied all these conditions.
Another improvement of the dialogs generated by the generic dialog creator is that text-edits now interpret a <Tab> character typed by the user as the command to transfer focus to the next text-edit of the dialog. This allows you to avoid the annoying switching between keyboard and mouse when completing the info of a large dialog, like Match Options.
The Engine-Output window was special by the fact that it contained two panes above each other, and a lot of label widgets were positioned next to each other above the text memos. The generic dialog crator already supported multiple panes next to each other, though, (for engines that had too many options to fit vertically), and a minute modification allowed those to be stacked vertically as well. Some code was added to allow label widgets (created through the Label pseudo-option) to be positioned on the same line (as could already be done for Button options), and allow some more user-supplied details on how they should be chained to the dialog edges, and that provided all that was needed.
The Eval Graph was special because it was a graphical window. The code for handling the drawing area was incorporated into the generic dialog creator, specified by a newly defined Graph option. After that, the Eval Graph could be generated by the dialog creator, and other dialog can incorporate graphical widgets, if they want (engine logos?). All the user will have to do is to specify a routine responsible for the drawing with the option, and it will automatically be called by expose events.
Using listboxes for engine selection
|
|
The comboboxes for selecting engines in the Load Engine and Match Options dialogs have been replaced by listboxes. This allows faster selection of the engines, because you don't have to open the comboboxes first. The latter was especially annoying when you needed to select a number of consecutive items from a long list for a tourney: you would have to reposition to where you were for each engine you added. Now you simply double-click the engines, without the mouse pointer having to move elsewhere in between. There are now also separate dialogs for loading first and second engine, so the combobox to choose this could be removed, as you already make the choice by selecting the appropriate dialog from the menu, without extra mouse click.
|
Structuring the engine listGrouping of engines is now also possible in XBoard. The fact that the engines are presented in listboxes makes this extra handy. Just double-click a group to see it open, with its name displayed as header, and click on that header to close it again, and go back to the 'root' list. As with WinBoard, the engines in a group are dlimited by lines "# GROUP NAME" and "# end" in the engine list. |
Observing another ICS game in a second windowThe main window is rather complex, not so much because of its layout and the type of widgets it contains, but because the widgets have all kinds of activity on clicking. In particular there are the pull-down menus of the menu bar, and various pop-up context menus on clicking the board (piece menu, drop menu). The generic dialog creator already contained code to generate menus, though, for ComboBox options, and the control elements for those are nothing but a one-menu menu bar, with a text-string written in front of it. This code was easy to re-use to do the main menu bar, as well as for creating pop-up menus. A new level of organization makes it possible to 'box' the menu buttons (or other controls) into a menu bar (which is also used for the button bar). The fact that the board can now be handled by XBoard's generic popup made it easy to add a second board window. So with the ICS options 'Background Observe' and 'Dual Board' both on, a game you are observing next to the game you are playing will now be displayed in a separate window, rather than side-by-side with your own game in a single, double-width window. The new window also contains its own clock and message field. (But no menus or button bar, and it will also not react to any clicking on it.) |
|
|
The file browser rewrittenXBoard so far relied on a file browser borrowed from GhostView, which was of a bit peculiar design, while the adaptations made in it to interface it to XBoard had made it a bit flaky. The file browser therefore has been completely rewritten, using XBoard's generic dialog generator, and its newly supported list boxes. The new design has two (scrollable) list-boxes, one for the folders and the other for the files in the current directory. It also has a combobox to select the type of file we are browsing for. By this we can filter on the usual extensions for the various file types, such as .pgn for games, and .fen for positions. Double-clicking on entries in the folder list enables you to navigate through the file system. Double-clicking on an entry in the file list will select the file. Depending on if you were browsing for actually accessing it (e.g from the Load Game menu) or just to get the name (as with the Browse buttons of another dialog), this will open the file, or put the name in the text-edit you were browsing for. Of course you can still type the filename by hand (if you need a non-existing file, for saving on). In that case the the browser can still be helpful, because it prepends the path name of the currently selected folder to the filename you type. When browsing for a path, that is the only thing it will copy to the text-edit. |
In Edit Position mode it has always been possible to move pieces from any square to any other square. New is that you can now also do this while keeping the Ctrl key pressed. This then moves the piece withot removing it from the original square, i.e. it becomes a 'copy' rather than a 'move' operation. This can be helpful for setting up a Pawn chain.
Some bugs were encountered and reported during the refactoring process, and they were corrected on the spot. In due time the fixes will find their way into the 4.6.x branch. We can mention:
Promotion popup
|
In a special branch of the git repository ('promopopup') there is a version of XBoard patched to use graphics to display the promotion choice, so that it more easily adapts to variants with different pieces. You just click on the image of the piece you want. This applies also to the piece menu in Edit Position mode. In that case, it selects both on right up-click and left down-click. |
Using XBoard as GUI for non-Chesslike board gamesAnother special branch in the repository ('alien') contains a version that has implemented some features needed to play other games than Chess variants. Such games might require moving multiplepieces during a single turn, or moving the same piece multiple times. In Checkers, for instance, there might be two different paths to the same final square of a multiple capture, so a move is no longer uniquely specfied by two squares, like in Chess. The most convenient way to specify such a move is by considering it to be multiple Chess-like moves, and let user or engine specify each 'leg' of the move separately. This is implemented by suppressing the turn-change at the end of moves that are entered with the Ctrl key pressed (with the mouse by the user) or suffixed by a comma (for moves in text form, i.e. from the engine, from PGN or through the move type-in). In Checkers of course moves can also have 'side effects', i.e. bring changes on other squares than those between which the piece moved, namely removal of pieces you jump over. XBoard now knows a number of variants where such 'alien' capture rules are automatically implemented, for Checkers-like, Go-like and Reversi-like captures, making it easy to support those games. For games with other side effects (e.g. Ulitma) there is a variant where an engine can send a complete board update after every move. Some games also allow you to pass a turn. This has been implemented by clicking the clock of the side you want to pass the move to, like was already possible in Edit-Position mode. (But only when legality testing is off,of course.) More about the XBoard Alien edition you can find here. |
|