Generic UCI GUIs within Mac OS X

[smrf]

Which Mac generic GUIs could be recommended for UCI engines?

I intend to write a 10x8 and 8x8 aware pendant to my Windows SMIRF for Mac OS X during this year, but I intend to base it on the UCI protocol then.

But if there already is a very sophisticated GUI, I doubt that there would be any need left still for such a multi geometry / variant approach.

[Tord Romstad]

Which Mac generic GUIs could be recommended for UCI engines?

I intend to write a 10x8 and 8x8 aware pendant to my Windows SMIRF for Mac OS X during this year, but I intend to base it on the UCI protocol then.

But if there already is a very sophisticated GUI, I doubt that there would be any need left still for such a multi geometry / variant approach.

I am not sure how you define "generic" and "very sophisticated". I have written two UCI GUIs for Mac OS X. One of them might satisfy your definition of "generic", but I fear none of them will satisfy your definition of "very sophisticated".

I have an old UCI GUI which supports rectangular 8x8 chess and 91-"square" hexagonal chess. Unfortunately, this GUI only works on old PowerPC Macs, and is no longer in development, because I don't own any such Macs. The problem was that OpenMCL, the tool I used to develop my GUI, was a PowerPC-only program. The good news is that there now is a port of OpenMCL (which in the meantime has been renamed to Clozure Common Lisp, or CCL) for 64-bit Intel Macs running Leopard. It's possible that I will soon be able to revive my old GUI once again.

My new GUI, which I started writing when I could no longer user OpenMCL, is written in Objective-C, and currently supports only normal 8x8 chess (like it or not, this is what 99.9% of all users want). This is free software, and you could in principle modify it to support any chess variant you want, but I am not sure how easy it would be. The source code is quite messy and ugly, because I learned Objective-C along the way, instead of studying it before I started writing the program.

In the future, I am more likely to try to revive the old GUI than to keep working on the new. Programming in Common Lisp is simply so much more convenient and fun than programming in Objective-C. I doubt that I will add support for 10x8 chess, if that is what you are interested in: In my opinion, the game doesn't really offer much beyond ordinary 8x8 chess (I am much more interested in shogi and hexagonal chess). However, the program will of course be released as free software, and you or anyone else would be free to add support for new chess variants. I am not sure how likely this is to happen, though -- there doesn't seem to be a lot of Lispers in the computer chess world.

Tord

[hgm]

Which Mac generic GUIs could be recommended for UCI engines?

I intend to write a 10x8 and 8x8 aware pendant to my Windows SMIRF for Mac OS X during this year, but I intend to base it on the UCI protocol then.

But if there already is a very sophisticated GUI, I doubt that there would be any need left still for such a multi geometry / variant approach.

Wanna make sure it is incompatible again, eh?

[smrf]

Well Tord, it would be fine to become able to see your GUI at work within a Intel based Mac OS X system. Hexagonal Chess is a feature, still not supported by SMIRF. I have not been able to estimate the amount of possible fans. Congratulations for your bravery to have followed your intention obviously despite of such considerations.

[smrf]

Which Mac generic GUIs could be recommended for UCI engines?

I intend to write a 10x8 and 8x8 aware pendant to my Windows SMIRF for Mac OS X during this year, but I intend to base it on the UCI protocol then.

But if there already is a very sophisticated GUI, I doubt that there would be any need left still for such a multi geometry / variant approach.

Wanna make sure it is incompatible again, eh?

Harm, I know that you are a fan of the Winboard protocol. Nevertheless I have some experiences with UCI having written a primitive SmirfMateUCI engine some time ago.

Because any 10x8 covering approach would exceed the "state of the art", it seems Mac OS X promises to be the platform with the smallest number of victims of incompatibilities.

[hgm]

Because any 10x8 covering approach would exceed the "state of the art", it seems Mac OS X promises to be the platform with the smallest number of victims of incompatibilities.

Except yourself, of course...

[Zach Wegner]

Well, speaking of GUIs, I have been kicking around the idea of making a GUI, or rather a UI. I would like a simple but sophisticated user interface that supports UCI and Xboard (and could easily be modified to support another protocol if necessary) that is very portable (just some basic wrappers for IO, time, and threading). I think Xboard is a great tool, but it lacks features that I would like such as running tournaments, managing engines, not displaying a board, etc. Something like this, that is intended only for engine vs. engine use, would not need a GUI. It could use a little ASCII board though.

However, I will probablyl never get the time to write it. Maybe if others are interested we could make it a team effort...

[smrf]

... However, I will probablyl never get the time to write it. Maybe if others are interested we could make it a team effort...

Despite of refuting those Open Source projects, which are customizable without the help of to be paid programmers like chess engines, which caused a severe devaluating e.g. of the work of chess programmers in the eyes of public consumers, I am not an opponent of creating application platforms like chess GUIs via Open Source.

One idea I had been following for a time was the establishing of such a GUI solution, based on WxWidgets. Thus I am not really experienced with that Wx tool and repository, it seems to promise a chance for a multi OS portable solution without special legality problems as partially encountered in QT as I presume.

But having already wide spreaded solutions like Arena in Windows kind OSs, there seems to be only a small demand for such a new multi OS approach. Therefore I currently will focus on a single OS, thus prefering a genuine solution.

[hgm]

I think Xboard is a great tool, but it lacks features that I would like such as running tournaments, managing engines, not displaying a board, etc.

I think it would be a strategic design mistake to try and add all that functionality into the same application. Running tournaments should be left to a dedicated tournament manager. Playing a Chess game or match to the GUI. Managing engines to an engine manager. That offers much more flexibility, as anyone can pick the components that he likes most, or write his own solution for a component that he does not like, without being confronted ith the problem of also re-writing everything that he did like.

I always use PSWBTM + WinBoard to run tournaments, and for me this is a quite ideal package. PSWBTM has a built-in engine manager. I can install engines in various configurations (e.g. time handicapped by a certain factor) next to each other. Setting up round-robins or gauntlets, from standard or EPD-/PGN-specified sets of positions is very easy. There even is support for life broadcasting of the games, and automatic updating of cross-table webpages and such.

As to the 'graphics problem': I really think this is a non-issue. WinBoard allows you to turn the display functions off by the /blindfold option. But even with the display on, the update is nearly infinitely fast on modern hardware. You just have to switch move animation off, as that intentionally drags it out (/animateMoves=false). When I do that, I cannot see the last 4 or 5 moves of a game at all, when both engines have the mate within the horizon, and start to move instantly. Communication delays in the engine-GUI pipes, and scheduling, will be much more of an issue than updating the display.

[Zach Wegner]

I think it would be a strategic design mistake to try and add all that functionality into the same application. Running tournaments should be left to a dedicated tournament manager. Playing a Chess game or match to the GUI. Managing engines to an engine manager. That offers much more flexibility, as anyone can pick the components that he likes most, or write his own solution for a component that he does not like, without being confronted ith the problem of also re-writing everything that he did like.

Well, they could possibly be separate components, but a tournament manager must be specifically designed for a certain GUI. So there goes the modularity... Of course, these components would be modular within the actual program, so someone could write their own little engine manager and stick it in.

I think the ability to manage engines is important, not just for creating engine collections, but for keeping track of my own. In Unix, there is no Winboard.ini, and there is no PSWBTM. So these components are left to brittle little shell scripts. One of the reasons that I want to make this is that I lost all of my old xboard scripts.

The tool is really designed for tournament managers and programmers. It wouldn't even have the ability to play a chess game, it would just be an arbiter.

As to the 'graphics problem': I really think this is a non-issue. WinBoard allows you to turn the display functions off by the /blindfold option. But even with the display on, the update is nearly infinitely fast on modern hardware. You just have to switch move animation off, as that intentionally drags it out (/animateMoves=false). When I do that, I cannot see the last 4 or 5 moves of a game at all, when both engines have the mate within the horizon, and start to move instantly. Communication delays in the engine-GUI pipes, and scheduling, will be much more of an issue than updating the display.

Well, that's not the problem really. What would happen in my old testing framework, is that a script would be running automatically taking a certain version and running gauntlets against various opponents for just a few games each. Because the script had to start up Xboard every time, a new window pops up and interrupts whatever I'm trying to do.

I also think that graphics are not necessary for the kind of tool I envision. Sometimes a simple curses-window can look more stylish than a window. It also contributes very significantly to code bloat and non-portability. Just think about how many features are available for winboard but not for xboard. That might just be a bad example, because Xboard was hacked later to have windows portability. But in my imaginary tool, you would have probably less than ten functions total that would be machine dependent.