Generic UCI GUIs within Mac OS X

[Tord Romstad]

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...

I have a set of Common Lisp classes and functions for running engine vs engine matches, test suites and similar tasks with UCI engines (no XBoard support, it's simply far too messy for me) without a GUI. There is currently no support for tournaments, but it would be trivial to add.

Because the code was written over a period of more than ten years, and was never intended to be used or seen by others, it is packed with rough edges, idiosyncrasies and inconsistencies, but if there is any interest, I could perhaps clean it up and make it available to the public. Most of the code is portable ANSI Common Lisp, except for a few CCL-specific functions for managing sub-processes in the engine communication code.

Of course, requiring a complete Common Lisp implementation just to run engine vs engine matches from the command line is probably a too heavy-weight solution for most people. For me, it is perfect, because I always have a Lisp running, and the Lisp prompt essentially is my command line: I use it for most of the tasks ordinary Unix users would do from the Bash prompt.

Tord

[Tord Romstad]

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,

This is wrong on so many levels that I don't know where to begin. I suspect that you, like many people, have misunderstood the meaning of the term "free software". It's an unfortunate fact that the word "free" in English has two entirely different meanings: "Does not cost money" ("gratis" in German, I suppose) and "free as in freedom" (probably "frei" in German). The word "free" in "free software" has the second of these meanings. It is perfectly possible (for free programs to be sold for money. In fact, it is quite likely that I will be selling a version of my own free chess program later this year.

Free software is about freedom for the user, more specifically the freedom to do anything he wants with the program, including modifying it for his own purposes, or use it as a basis for his own commercial products. It does not devaluate the work of paid programmers; on the contrary, it enhances the value. This is almost tautologically true: Given a free program and a functionally equivalent proprietary program, everything you can do with the proprietary program just as well with the free program, but you can use the free program for things you wouldn't be allowed to do with the proprietary program.

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.

The problem with cross-platform GUI libraries are that they don't look or feel quite like native applications on any platform. This is not because the libraries are badly written, but because the user interface paradigms on different platforms are not the same. Mac OS X applications written with QT or WxWidgets don't look good, and are awkward and uncomfortable to use. I guess the same is true in Windows, although Windows users seem to be much more tolerant about things like this.

In Mac OS X, Cocoa is definitely the way to go. Don't let Objective-C scare you; it's a simple language, and can be learnt in a few hours if you already know C. It is far more comfortable to work with than C++.

Tord

[Tord Romstad]

Well Tord, it would be fine to become able to see your GUI at work within a Intel based Mac OS X system.

I hope I'll find time for it. My problem is that I always have too many projects competing about my time: My chess engine, my chess GUI, my shogi engine, my shogi GUI, the iPhone port of my chess program, and numerous non-chess-related projects. With only one or two hours per week of hobby programming time, it's impossible to find the time for it all, and all my programs end up as buggy and incomplete proofs of concept.

Hexagonal Chess is a feature, still not supported by SMIRF. I have not been able to estimate the amount of possible fans.

No more than for 10x8 chess, I think. Interest in obscure chess variants will never be wide-spread. If you want a big number of fans, stick to the three big officially recognized chess variants (western chess, xiangqi and shogi).

Congratulations for your bravery to have followed your intention obviously despite of such considerations.

Thanks, but it didn't really require any bravery, because I was programming only for my personal enjoyment.

Tord

[smrf]

... This is wrong on so many levels that I don't know where to begin. ...

I have not told about what Open Source is meant to be, but what users are making out of it. And they confuse it with warez, or programmers are making clones, doing patchworking and nevertheless participate on tournaments.

... In Mac OS X, Cocoa is definitely the way to go. Don't let Objective-C scare you; it's a simple language, and can be learnt in a few hours if you already know C. It is far more comfortable to work with than C++.

In the meantime I have tried to get familiar with Objective-C, which now has a new version 2.0, e.g. including a GC, which seems to be a kind of sacrileg to long time ObjC programmers. It is not the fastest language (e.g. because of the absence of inlineable class methods), but for the GUI module this is not that important. An engine could be written e.g. in C or C++, which is not at all that uncomfortable.

[Matthias Gemuh]

Wanna make sure it is incompatible again, eh?

What's wrong with that ? Tired of writing Smirf adapters ?


Regards,
Matthias.

[Matthias Gemuh]

(no XBoard support, it's simply far too messy for me)

Tord

Very right !
Even engine authors don't know that. They pick one path each that works for their engines and off they go. A GUI however has to cope with a mess unthinkable in the rather neat one-way UCI world.

Mathias

[Guetti]

I would like to see a modular approach, like a module for UCI protocol handling, one for xboard, one for the graphics etc. With this, changes in the protocols could be easily carried across platforms. This would avoid he whole Winboard != xboard mess. Maybe these modules are best written in C/C++.
The GUI part could be written in common language that most programmers can use (Java, wx, not LISP!) or with this modular system, a GUI could be developed individually for Linux, OSX and Windows.

[smrf]

... The GUI part could be written in common language that most programmers can use (Java, wx, not LISP!) or with this modular system, a GUI could be developed individually for each system.

A GUI is the part most close to an OS. Thus if the OS demands for a special language, it is hard to escape from this. In contrast to Microsoft systems in Mac OS X there is a clear priority call for to use Cocoa via Objective-C. The next best alternative would be to use a multi OS framework like WxWidgets, but that would indeed skip some beutifying details of the OSs involved.

[Guetti]

... The GUI part could be written in common language that most programmers can use (Java, wx, not LISP!) or with this modular system, a GUI could be developed individually for each system.

A GUI is the part most close to an OS. Thus if the OS demands for a special language, it is hard to escape from this. In contrast to Microsoft systems in Mac OS X there is a clear priority call for to use Cocoa via Objective-C. The next best alternative would be to use a multi OS framework like WxWidgets, but that would indeed skip some beutifying details of the OSs involved.

I absolutely agree for OSX. I would even go as far as to ask why start a zero, why not use the Tords Glaurung2 GUI as a starting point?

[smrf]

I absolutely agree for OSX. I would even go as far as to ask why start a zero, why not use the Tords Glaurung2 GUI as a starting point?

Because I do not know, whether it will be helpful. Not because of quality aspects at all, but because I want to integrate 8x8 and 10x8 geometries, random array variants like Chess960 and CRC, different castling models as used in XFEN, new piece symbols, which could not all be based on fonts, extended UCI protocol, extended PGN understanding, and as a option the use of UTF8 in PGN files announced via an early token [UTF8 "1"].