I need a name for a chess gui application

[Guenther]

...

Very simple stuff, as it should be at this stage of development.

BTW which font did you use for the pieces here? They look neat and
I think I don't know this one yet, because the Knights don't look familiar
to me.

[hgm]

I'm planning on doing the full WB 2 implementation first. Then I will take a closer look at the extensions of the protocol. I'm most interested in features that are in both WB and UCI protocols.

This is exactly what most of the protocol extensions are for: to also be able to send to WB engines the things you would normally send to UCI engines, and the GUI is likely to have anyway. Such as hash + egtbCache size, nalimov path, and max nr of CPUs.

I think it would be wise to at least take a look at the protocol extensions before you implement anything, as the protocol you finally want to support might impact the design of other parts of your GUI, such as the user interface. E.g. would you allow the user to only enter a path for Nalimov tablebases, or would you also put a path for bitbases on the menu.

[ilari]

...

Very simple stuff, as it should be at this stage of development.

BTW which font did you use for the pieces here? They look neat and
I think I don't know this one yet, because the Knights don't look familiar
to me.

It's not really a font. They're SVG images (vector graphics) grabbed from Wikipedia: http://en.wikipedia.org/wiki/Chess_piece. They were licensed under GPL, BSD, etc.

[AdminX]

Enterprise!

To boldly go, where no GUI has gone before ....

But wait, that is alot to live up to.

[ilari]

I think it would be wise to at least take a look at the protocol extensions before you implement anything, as the protocol you finally want to support might impact the design of other parts of your GUI, such as the user interface. E.g. would you allow the user to only enter a path for Nalimov tablebases, or would you also put a path for bitbases on the menu.

I do read the discussions, I just don't participate that much. For example we don't trust the result command of WB engines, and we automatically end the game when a draw by repetition/material/50 move rule happens, unlike Xboard. I made that decision partly based on your input.

As far as gui options go, we're not that far yet, we haven't even implemented the UCI config dialog(s) yet.

[hgm]

I do read the discussions, I just don't participate that much.

OK, great. I just wanted to point it out.

For example we don't trust the result command of WB engines, and we automatically end the game when a draw by repetition/material/50 move rule happens, unlike Xboard.

Well, XBoard does that too now. But you might want to make it optional, like XBoard does. Checkmate and insufficient-mating-material draws are one thing, as FIDE rules clearly specify that such conditions end the game. But not allowing engines to continue after 50 moves or 3-fold repeat is a deviation of FIDE rules, and some users might object to that.

I made that decision partly based on your input.

As far as gui options go, we're not that far yet, we haven't even implemented the UCI config dialog(s) yet.

WinBoard doesn't have that yet either, and I am in doubt how useful it would be to add it. It is really something that belongs in the engine manager, and not in the GUI.

The UCI standard options are a clear exception, though: it makes sense to set parameters in the GUI for memory and CPU usage, location of end-game tables, and such things that you would want applied to every engine.

[ilari]

For example we don't trust the result command of WB engines, and we automatically end the game when a draw by repetition/material/50 move rule happens, unlike Xboard.

Well, XBoard does that too now. But you might want to make it optional, like XBoard does. Checkmate and insufficient-mating-material draws are one thing, as FIDE rules clearly specify that such conditions end the game. But not allowing engines to continue after 50 moves or 3-fold repeat is a deviation of FIDE rules, and some users might object to that.

Xboard only has to care about Xboard engines which usually claim draws by themselves. Our gui often has to use both protocols in the same game, and because UCI engines don't claim draws, our gui has to do it for them. But for games where humans are playing automatic draw claims should of course be optional.

[ilari]

Well, we finally changed the name. We chose Cute Chess because we like cute things, and because Qt (our C++ toolkit of choice) is an abbreviation for cute. Thanks again for all the suggestions.

[hgm]

Yes, I know UCI engines are highly challenged. But claiming draws on behalf of an engine is something different than adjudicating a game. Perhaps you should only have engine claim a draw if they report a score below their contempt factor, and treat WB engines like you treat humans. (Just a suggestion.) For adjudication in XBoard I let the user decide after how many repeats or reversile moves he wants to adjudicate draw.

One more remark: when you get to implementing ICS client functions, beware that ICC does not send meaningful castling rights in Chess960, not even in the initial position.

Note that I have hacked the Lasker.2.2.3 server to allow ICS play of capablanca and gothic. For this I had to extend FICS protocol, in particular the format of "board 12", which can now contain an arbitrary number of files and ranks. This is never ambiguous, as the ranks are delimited by spaces, and the last rank is followed by an isolated B or W (for the stm). I use A and C for the capablanca pieces.