OSXBoard

[Chris]

Progress marches on.

Harm has been doing a lot of the code factoring for me and I have a modest amount of functionality to show.

OSXBoard can parse, display and navigate PGNs.
I can grasp and drag pieces with Cocoa drag and drop.
Basic alerts display. PlaySound plays a sound.
The application links in most about 30 files from xboard.

I haven't quite gotten a chess engine to run yet. Soon.

When I get to that point, I'm going to clean up my project a little and do a code dump.

[BrightRhino]

Hi,

I am interested in helping with development and testing of the mac app, I am registered as an apple developer and would be glad to help test on various macs, all the iPads, iPhones and iPod touches. I just started playing chess again last week after downloading chess with friends, and started looking for mac tools, but a native mac gui is nowhere to be found.

Do you have a git repository somewhere I can clone and compile?

I am a complete beginner at chess programming, this should be a fun exploration.

Anything I can do to help, let me know.

Thanks,

Alex

[H.G.Muller]

I haven't heard from Chris for some time. I will contact him to see how he has been progressing. More than a month ago he sent me some code, but it was not complete enough for someone to compile the XCode project. (Which I could not do anyway, having no Mac.) It was only the Objective C files, but the window descriptions were missing. So I never bothered to put it on line.

The past two weeks I have done a major overhaul of the XBoard front-end code. The main purpose was to achieve a better separation of platform-dependent code and program logic. This operation is sort of finished now, and reduced the amount of source code that depends on the X11/Xaw widget set by more than a factor of 2. IMO this version would be ideal for porting to other platforms, as most of the remaining X11/Xaw code is of a very basic nature. My incentive for doing this is that I want to port XBoard to Android myself.

[BrightRhino]

Great, I would be interested in seeing the code he sent to begin understanding anything about Xboard. The only other Mac OS based GUI I have found is the stockfish 2.0 version, are you aware of any other open source work I can look at? It would be great to have this running on the mac and iPad. Is your overhaul available to download yet? I would like to begin to understand the thinking behind Xboard.

Thanks,

Alex

[H.G.Muller]

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.