OSXBoard

[Chris]

Hi, I'm Chris Sears. I think my name is in the XBoard sources somewhere. It's been awhile.

Anyways, I'm porting the XBoard backend to OS X Cocoa. For lack of a better name, I'm calling it OSXBoard. I'd say it's at the alpha minus stage. OSXBoard can parse and display games.

I've isolated the back end pretty well. So I haven't had to do any source changes to the backend. Hopefully that will remain the case.

The OSXBoard frontend is written in Objective C and uses model view controller. One model is the parser. Another will be engines. A third will be ICS, ....

I'd like to flesh OSXBoard out into a full fledged Mac program and put it in the App Store for distribution. Of course, it'll still be open source but I just think it'd make distribution easier.

Anyways, I'd appreciate hearing from any testers and collaborators. I could especially use some help figuring out some of the wacky and weird games and modes that have gotten added over the decades.

Chris

[H.G.Muller]

This is really great news! I know basically nothing of Macs, and even less of iPads, (or Objective C), but if I understand you correctly, your work would enable running XBoard these machines? And would that work for iPhones too? (But if it did, the screen might be too small to make this useful?)

Despite the fact that lots and lots of features have been added the past years, the XBoard front-end has actually been shrinking, as I have been systematically purifying it of back-end code, moving anything I encountered that was not obviously platform dependent to the back-end, so that it could be shared with WinBoard and future ports to other platforms. E.g. almost all mouse event handling is now done in the back-end.

I am prepared to support any modification you need in the back-end to make porting to OS X easier. One obvious issue could be to move composing the board to the back-end (i.e. calculation of the coordinates of all board elements, whether squares should be light, dark or blacked out, which square should be highlighted, which pieces are 'floating' and where they should be overlayed, etc.). Currently the board-drawing routines have very poor front-end / back-end separation, so all the complexity of the back-end component has to be replicated in any new port (and indeed is duplicated between XBoard and WinBoard). Until now there never was much incentive to do anything about this, though, as we never needed to change much in either of those.

In my vision the front-end should contain nothing more than platform-independent wrappers for the necessary low-level functions (Create a window, create a menu, draw a line / circle / rectangle, render text, draw a bitmap.) The decision of what items are in the menu, and what they do, how large the windows are and where they should be positioned, should all be taken in the back-end.

As I would like to have an Android port of XBoard too, I really think it would pay off to invest a bit in enhancing the portability. So let me know how I could assist in this respect!

[Chris]

Harm,

xboard and the backend were pretty well separated. The issues I had were with SquareColor and some global variables in xboard.c. For now, I just copied them into glue.c. I'd like to move SquareColor into backend.c and all global variables into AppData proper. Looking forward, I can imagine multiple threads. So making the backend threadsafe would be helpful. Flex can generate reentrant code with %option reentrant (`-R')

So far, I've only parsed a PGN file and displayed a board. Basically, InitBackend1,2(). Not nothing but at the same time not a lot.

My strategy so far has been centered on glue.c and glue.h.

glue.h doesn't include config.h and just declares some accessors. glue.h doesn't include any backend include files, firstly because of namespace conflicts. Also, the frontend and the backend may be compiled differently and structs may align differently and may be differently sized

glue.c includes config.h and the backend includes as well. The OSXBoard frontend actually gets compiled with different flag settings so I'm constrained to using accessors and strings. This isn't so bad.

OS X, Cocoa and Objective C are pretty clean and modern. IOS (iPad and iPhone) is a derivative of OS X and so an OS X frontend will go a long way towards an iPad client. However, while the iPhone is IOS, it's a lot smaller and so it would have a lot of unique UI problems.

A good OSXBoard should also make an Android port easier since the frontend and the backend will be further decoupled.

I haven't really hooked up any real UI code yet. Just BMPs and graphics. When I get the UI component of PGN parsing done, I release an alpha code dump. In the meantime, if you PM me your email, I'll send you glue.[ch] to give you a more concrete idea.

Chris

[H.G.Muller]

OK, I'll have a look at it.

From where you are now, making it such that you can actually enter moves (and thus play a game against an engine) should be quite easy. You only have to connect clicks on the board to the back-end LeftClick and RightClick routines, passing the board coordinates of the click point.

The difficult part of the front-end is getting the animateMoving and animateDragging to work. (DragPieceBegin etc.)

Anyway, if you have any questions about all the stuff that was added since version 1.2, just fire away. I have actually no idea what 1.2 was like; I stepped in at 4.2.7! From reading the 'Contributors' section I got the impression that the front-end still underwent significant improvements (such as the animation) between those.

When you get to porting menu dialogs, the important function is GenericPopup in xoptions.c, which is a table-driven universal dialog generator (which was needed anyway, to generate the Engine Settings dialogs on the engine's specifications),. The tables to define what should be in the dialogs are also in that file, although they are really back-end. (But WinBoard already had all dialogs implemented in a dedicated way, so it doesn't use its universal dialog generator for this, so the tables are not needed there.) I guess xoptions.c should be split up into xpopup.c that contains the code of GenericPopup, associated callbacks and the wrappers to access individual control elements, and a back-end file options.c, containing all the option tables and platform-independent button-handlers. Which would not be used in WinBoard, but could be shared between XBoard, OSXBoard. (Wouldn't it be better to call this MacBoard? We could also have an iBoard then. )

[Chris]

Oops. So I used 4.4something. I just downloaded 4.6 and I'm forward porting the code.

What's the deal with args.h == args.c ?

Chris

[H.G.Muller]

Yes, 4.6 would be the best starting point, and actually less work than 4.4. It gives you way more front-end, with less code. Beware that it remembers its settings in ~/.xboardrc, though, so that changing the default settings of options in the code and recompiling might not have the expected effect (i.e. not have any effect at all). The recommended way to change defaults is either in the master settings file (/etc/xboard.conf).

Args.h is #included in both xboard.c and winboard.c. IIRC the autotools did not recognize the dependency if it was called args.c, and renaming it was the easiest fix. Originally it was code from winboard.c, and I wanted it to be shared. But it contained lots of platform-dependent stuff, that had to be declared in a different way for WinBoard and XBoard, and #including it automatically gave it the correct context. I guess this should be fixed in a cleaner way one day, by moving lots of declarations now local to xboard.c and winboard.c to xboard.h and winboard.h, and making args.c an independent back-end file including one or the other, subject to an #ifdef WIN32.

Sorry about that. But what can I say... It worked, and I am lazy...

A question:

Would you be willing to join the official GNU-Savannah XBoard project ( http://savannah.gnu.org/projects/xboard ), and do your development on the master branch there (putting all files for the OSX front end in a new sub-directory OSX)?

[Chris]

Perhaps I'll just be able to include args.h in glue.c. I understand that context and basically providing that context is the reason for glue.c's existence.

FWIW, looking at Core Data and IOS on iPad, the file system kind of goes away altogether. Instead you have an Entity-Relationship database and the idea of ~/.xboardrc wouldn't make any sense. Cocoa AppKit has some pretty good preference capabilities.

I suppose that Savannah is Gnu Freshmeat? Yes, but let me get something worth releasing.

Chris

[Chris]

I would recommend splitting args.h out of xboard into a separate args.c file.
All defines, structs and typedefs should go into common.h.
Any X/Win dependencies should be ifdef'd.
All global variables go into AppData. They are mostly already are there.

The backend seems to make a lot more calls to the xboard.c frontend in 4.6 which I'll have to duplicate in glue.c

Although I got args.h to compile in glue.c I'm going to back that out and just fill in appData by hand for now.

[H.G.Muller]

Originally putting all settings in a single appData structure was a necessity to make Xt handle the command-line options. But inWinBoard it had no function, and when WinBoard development surged ahead on its own, many of its options only lived in the front-end, and were declared as global variables in winboard.c. (And not only display options, as many features that logically were back-end were also entirely implemented in winboard.c.)

I agree that it would be better to restore the systematics, and relocate every option value to appData. Until now I never attempted such large-scale refactoring of the code if there was no imperative reason to do so ("if it ain't broken, don't fix it!"), but this seems a good time to fix it. The header-file situation in XBoard is currently quite awful; many globally used variables do not occur in header files at all, but are simply declared extern in several .c files. This is invited by the fact that there isn't a clear policy for which kind of variable would should go into which header.

To this I should add that backend.c has really grown unwieldly large, and it might make sense to split it up. E.g. put all ICS stuff (receive_from_ics, parse_board12) in one file, the basic handling of the stack of boards (MakeMove, ApplyMove, game parsing) in another, engine stuff in a third (HandleMachineMove), the UI stuff (UserMoveEvent, ...Event, LeftClick, RightClick) in a fourth, all seek-graph stuff in a fifth, perhaps the database stuff (FindPosition) in a sixth... This wouldn't really help you making the new front-end, though.

How can we best proceed? At savannah.gnu.org we currently have a v4.6.x branch and a master branch, which so far are completely in sync, as we are still working up to the release of 4.6.0. This seems the first time we want to make a patch that should not go into 4.6.0. But starting the post-4.6 era with some code refactoring in master doesn't seem a bad idea. So shall I work on refactoring the existing front-ends to use an args.c in stead of the existing args.h, with all option settings moved to appData, and push that to the master branch? Or should I wait pushing anything until your work is there?

[Chris]

I would encourage you to do the appData+define refactoring now, an early spring house cleaning. It would make my life easier now, since I'd have to (to a degree I already have) do a hacky version only to be backed out later.

Maybe anything explicitly meant for the front end could be static in xboard.c or winboard.c and anything backend could be in AppData. I just hate tracking down loose variables.

As for splitting out those subsystems into separate files, that's a good idea and it should be easier. FWIW, the above refactoring should leave args.c as just another subsystem.

[H.G.Muller]

One important question:

Are you aware that in the GNU Savannah repository there is a branch gtk-xt, which contains a port of XBoard to the GDK+ widget set, which sort of works? I just learned that there is a native OS X version of the GDK+ library available. Wouldn't this already be the same as what you are trying to achieve now?

[Josh Pettus]

Awesome! Can't tell you how long I have dreamed this were possible, but not knowing the fist thing about coding left it a mere pipe dream.

Thank-you!

[Chris]

I did see the gtk version on the list of Savannah files, but I'd rather do a full blown Cocoa port for OS X. Cocoa is pretty darned good and the App Store is a good distribution mechanism. This will still be open source, of course.

FWIW, the native Chess client on OS X is open source, http://www.opensource.apple.com/source/Chess/Chess-110.1.23/.
It's really an Open GL 3D showpiece and bundles FairyMax.
I've looked at it, but it's mostly GL code. Not much use for OSXBoard.

BTW, I could see just calling it XBoard on OS X.

DarkLord, can you help us out testing?

[ZirconiumX]

Would you mind a person with an ancient version of OS X (10.4) testing a ppc port (if available)?

Matthew:out

[Josh Pettus]

I would be happy too,

My laptop is an older macbook pro, intel core 2 duo with 10.7 lion.

[Chris]

Zirc, I'll look at that. I hadn't planned on it, but I'll look at it.
Dark, great.

It's a rather boring application right now. It can open/parse a PGN file. It can display/navigate a game. Thrilling.

Next up is either ICS or a chess engine. Then I'll have an alpha.

Chris

[Chris]

You can't develop for PPC anymore with X Code 4.
Apple has a way of enforcing forward progress and addition hardware purchases.

Chris

[Josh Pettus]

Well there are ways of getting Xcode 4 to compile PPC people have found, but it takes quite a bit of work and rest your whole current setup. I think it also has you install Xcode3 along side.

[imai]

Chris,
This is a great initiative. I can not help you with the code but I like to participate in the testing. My hardware is the same as Darklord's but I can install older OS on my macbook via VMWare. I assume that you are registered in macdeveloper.net and there will be lots of testers there, among myself.
Hope you and Harm have a very productive cooperation.

[Josh Pettus]

Ya know, "Macboard" would have a nice ring to it.