The overhaul is currently available from http://hgm.nubati.net/cgi-bin/gitweb.cgi
, in the 'refactor' branch
. It is pretty much finished; I have already started making upgrades of features in it that have become easy.
This overhauled version is based on a somewhat unusual design. XBoard has always been based on the (by now pretty archaic) Athena widget set (Xaw) for the X-toolkit, which meant the interdace with the system was quite low-level. XBoard needs a dialog of variable content (which only becomes known at run time), for presenting the engine options to the user (the Engine #N Settings dialogs). For this it contained a routine that would transform the list of options received from the engine to a dialog with the appropriate controls for setting the options. The engine could specify CheckBox, TextBox, FileName, PathName, Spin and ComboBox options, as well as Buttons.
In the overhauled code, this list-driven GenericPopUp routine (in the source file xoptions.c) has been made responsible for creation of all windows, by including some new 'Option' types that engines would never provide, for ordering special elements needed in some of the windows (like ListBox for the Game List, and Graph for the Eval Graph). This way it could be used for creating all required windows, by simply feeding it prepared lists of Options, where a global flag would specify if an change in the option settings would have to be sent to an engine (and which), or to a variable in XBoard.
GenericPopUp was also made a bit more clever with respect to designing the dialog lay-out, by paying attention to lay-out instructions stored in otherwise unused Option parameters. Engines never provide such layout instructions with their options, so in the Engine #N Settings dialog they simply go one option per line, but for the prepared lists the programmer can order some option types to go onto the same row as a previous option, to have a non-standard height or width, be 'chained' in a non-standard way to the dialog edges, etc. There were also some option types added for layout purposes, like Label (for immutable texts) and Break (to start a new colomn, which for engine-supplied lists would automatically happen after a certain number of options).
So a large part of the front-end now consists of completely platform-independent lists of options, describing what should go into the various dialogs, and routines to specify what actions should be taken when the user clicks OK on that dialog, (other than just copying the settings to their designated locations), or hits a dedicated dialog button. This mostly resides in the file dialogs.c, although (mainly for historic reasons) some of the more complex windows have their own files for platform-independent code (nengineoutput.c, ngamelist.c) and X11 front-end code (xengineoutput.c, xgamelist.c, xedittags.c, xevalgraph.c, xhistory.c).
Other platform-independent code, associated with the menus, has been located in a file menus.c. This is mainly tables of what menu items should be present, and what platform-independent routine they should invoke. (E.g. clicking New Game in the File menu directly calls ResetEvent() in backend.c, and clicking Match... in the Options menu calls the routine in dialogs.c to pop up the Match Options dialog by feeding the descriptor list for it to GenericPopUp.) It also contains the tables for what menu items to enable or disable in the various modes of XBoard.
All code for interacting with the OS in a non-graphical way (spinning off engine processes, connecting to the internet) has been moved to a file usystem.c. In XBoard this is of course Unix-like code, (using fork() and pipe() system calls), but as many OS are based on Linux, (OSX, Android), chances are that the stuff in there is usable on other platforms without modification. (Not on MS Windows, though.)
Most code associated with drawing the Chess board has been moved to a file board.c. This is a platform-independent file that decides about the board format (number of ranks and files), which color each square has, which pieces are on them, if they are highlighted or marked, etc. Finally it calls a platform-dependent routine DrawOneSquare (in xboard.c) to draw a completely dressed-up square at given board coordinates. It also contains a lot of code for animation of moves (dragging the piece with the mouse). Chances are that on more modern system you would not need this code, because dragging around an image might be a basic OS primitive (e.g. defining the mouse cursor by this image), but XBoard implements this by carefully copying rectangular areas between board and buffer bitmaps. Apart from the routine that does the actual copying and the one that renders the dragged piece (which again are in xboard.c), the code to calculate what should be copied and where is completely platform independent, and was thus put in board.c.
What is left in the source file xboard.c is mainly code to prepare the drawing (create bitmaps from built-in pixmap image descriptions, or load them from file). It also contains main(), which does initialization, reads the settings file and command-line options (through tables and code in an #included file args.h, so it could be shared with WinBoard), and orders popping up of the main window(s).
I will try to put Chris' code on-line in another branch of that same repository.