how to make a chess interface

[lucasart]

Incidentally, my xboard cannot work anymore (arch linux +kde; something about... Failed to start 1st chess engine... ) so my chess program has to stop for a while; there is so far no good-enough replacement linux chess interface for uci engines meant for programmers.

* cutechess-cli is pretty amazing. you should give it a try. but it's a CLI for automated tournament testing (including parallel testing)
* cutechess (GUI) is baking. and i'm sure it will soon be the best GUI for Linux by a long shot. i hope ilari releases a compile soon, even if it's an alpha.

[hgm]

Incidentally, my xboard cannot work anymore (arch linux +kde; something about... Failed to start 1st chess engine... ) so my chess program has to stop for a while; there is so far no good-enough replacement linux chess interface for uci engines meant for programmers.

I notice this only now.

I am not sure which XBoard version you are using, but I would be surprised if any version had any problems in that area. If it says 'Failed to start 1st chess engine' it is not joking, and it usually means there is some error in specifying the engine command or the path.

What command exactly are you using to run your engine with XBoard?

[Chan Rasjid]

Hello Muller,

The version is 4.6.2.

The command is :
xboard -fd '/home/rasjid/chess/polyglot' -fcp 'polyglot fruit.ini' -sd '/home/rasjid/chess/polyglot' -scp 'polyglot fruit.ini'

The executable polyglot and all the .init files are in /home/rasjid/chess/polyglot.

It used to work; but recently I did some dumb things and had to reformat my hard drives and reinstalled my arch linux. After that, xboard cannot work.

I did noticed there were some discussion somewhere and you (maybe ?) mentioned it was some new changes and also about the polyglot paths, etc. I could not get it work even if I put all polyglot, etc into /usr/share.

But it's ok; my chess porgram is hibernating.

Rasjid.

[hgm]

Note that on Linux systems you cannot run polyglot in the current directory by simply typing 'polyglot'. You have to type './poyglot', or you would get the error message that the binary is not found. So -fcp "polyglot ...." cannot work unless the polyglot binary is in a directory in your path, like /usr/games or /usr/bin . This is probably where it was before your disk crash.

[Don]

Note that on Linux systems you cannot run polyglot in the current directory by simply typing 'polyglot'. You have to type './poyglot', or you would get the error message that the binary is not found. So -fcp "polyglot ...." cannot work unless the polyglot binary is in a directory in your path, like /usr/games or /usr/bin . This is probably where it was before your disk crash.

Some people put "." in their path so they can run any program in the working directory. However this is considered a security risk - so I have never done that.

Don

[PK]

perhaps it would be a good idea to do some kind of query where users and/or programmers find the existing GUIs lacking. I have tested both Glass and Rodent under a variety of UCI-compatibile GUIs and concluded that adding some useful features either cannot be implemented or are mutually exclusive:

1) if an engine has a set of predefined personalities, under virtually any GUI it cannot use BOTH personality files and user-defined options. the reason is that I cannot load personality file AND refresh option values modified by that file. this can be overcome by using an ini file determining what the user wants (choice of personality files or manual setup)

2) some GUIs display text messages ("info string" etc.), some do not; writing a chatty engine would tie me to Arena and exclude Fritz GUI.

3) it would be nice if an interface would display everything after a "pv" keyword. i.e. if I try to send a ponder move in brackets before analysed line, I see it in a debug window of Arena, but not on dislay;

4) it might be useful to extend UCI protocol adding a "comment" tag, i.e.

"info depth 4 nodes 756 pv d7d5 e4d5 d8d5 b1c3 d5e6 score -45 comment don't like it"

[hgm]

1) if an engine has a set of predefined personalities, under virtually any GUI it cannot use BOTH personality files and user-defined options. the reason is that I cannot load personality file AND refresh option values modified by that file. this can be overcome by using an ini file determining what the user wants (choice of personality files or manual setup)

In WinBoard an engine can send feature done=0 to clear its list of options, and then resend all the options with new default values. I suppose ICS engines could also just resend their 'option' commands in response to a 'setoption' that selects a new profile. Not sure if every interface would overwrite previous values, though, or just add them as duplicates.

2) some GUIs display text messages ("info string" etc.), some do not; writing a chatty engine would tie me to Arena and exclude Fritz GUI.

Well, WinBoard would display them...

3) it would be nice if an interface would display everything after a "pv" keyword. i.e. if I try to send a ponder move in brackets before analysed line, I see it in a debug window of Arena, but not on dislay;

Then you should really change to WB protocol.

4) it might be useful to extend UCI protocol adding a "comment" tag, i.e.

"info depth 4 nodes 756 pv d7d5 e4d5 d8d5 b1c3 d5e6 score -45 comment don't like it"

Why not just keep 'string' in stead of 'comment'?

[Chan Rasjid]

Hello Muller,

Note that on Linux systems you cannot run polyglot in the current directory by simply typing 'polyglot'. You have to type './poyglot', or you would get the error message that the binary is not found. So -fcp "polyglot ...." cannot work unless the polyglot binary is in a directory in your path, like /usr/games or /usr/bin . This is probably where it was before your disk crash.

From polyglot readme :
To use PolyGlot with XBoard, you would type something like this:
> xboard -fd 'ini_dir' -fcp 'polyglot engine.ini'

I remember I followed the usage as above and it worked with the 'older' xboard; my xboard
now is the most recent (few weeks)from arhc linux package and it does not work.

This also failed:
xboard -sd '/home/rasjid/chess/polyglot' -scp './polyglot fruit.ini'

"failed to start 2nd chess program on local host:./polyglot (or polyglot)
: No such file or directroy"

I googled and there were some posts elsewhere where others too faced the same problem:

Re: Xboard 4.4.0 for Mac OSX?

Postby H.G.Muller » 01 Jan 2010, 17:28
I think we hd this problem before, and it could be traced to the WinBoard code for invoking Polyglot did not work with the settings used in XBoard for the install directory when -polyglotDir is not equal to ".". I have addressed this in the development version of XBoard, doing away with the polyglot_1st.ini files altogether, but this is such a radical change in the way things work that we did not dare to include this new code in the stabe 4.4.x version.

Currently the only soluton is not use the -polyglotDir option in XBoard. This requires the Polyglot executable to be inside the xboard directory (where the polyglot_1st.ini is made), or in a directory in the PATH, like /usr/games, where it would normally be installed (just as xboard) in Debian systems.


Re: Xboard 4.4.0 for Mac OSX?

Postby H.G.Muller » 01 Jan 2010, 22:58
Well, when you explicitly invoke Polyglot, it does not really matter where you put it, provided that the executable pathname and polyglot.ini path name are consistent with the dirctory specified with -fd. The restriction on the location of Polyglot only applies when using the -fUCI argument.

Thanks,
Rasjid

[Chan Rasjid]

Hello,

Muller commented that it is 10x or 100x more difficult to write a chess GUI from scratch than it is to write a chess program. I think it depends on what detail features we want. Pychess GUI is one written from scratch and I think it is not very much more difficult than writing a full feature UCI chess program. It depends on whether a programmer is familiar with graphics programming.

It is ok if we only want UCI compatibility; but for UCI + xboard protocol as in the xboard attempt, it would be hellish. I doubt anyone would find it entertaining to think of writing from scratch a new replacement for xboard. Even getting an updated version of the xboard protocol would be difficult as compared to the single file UCI protocol. Add to the mess about attempting backward compatibility so that old xboard engines may still run!

For me, the only difficulty (special or unusual features aside) in writing a chess GUI is the graphics programming part - the glade/GTK+ widgets and cairo graphics part and they are more difficult than plain C/C++. If somehow I have a partner who can do for me the UI outlines and give me the widget features I want, I think it is not too difficult for me to put in the codes for the callback functions. As an example, the earlier codes I posted is an outline for the menu 'Games->new->start' to run a new game between two UCI engines. The difficult part is to implement the UI for users to edit preferences, options,to set up new engines, etc. Or maybe my implementation of a chess GUI is fit only for cavemen!

Tell me about taking over Tim Mann's xboard and to maintain or improved on it - impossible! I think it can end only in a mess and not much benefits to users can come from it no matter how much effort is put in; if enough of effort is put in to make it really good, it is like reworking it in assembly which is 10x or 100x more difficult.

Taking over the old xboard codes have too much of constraints and it is the antiquated widget library used that would posed the greatest difficulty. Modern unix programs all make use of the latest graphics library. As an example, if we need to select/save a file, the file tree would pop-up and we could easily select what we want. Only GTK+ and QT have such easy to used standard widgets. So in my experimental GUI, I could get out the initial chess position. I could resize it using my mouse and it scales automatically as auto scaling is a feature for some standard widgets. xboard cannot resize the board; I think it also cannot flip the board from menu (or I miss it). This is not to point out the failure of Muller. I myself have to do some work before I could repaint the board when the user chooses Board->Option->FlipBoard. I think with the xboard code, it would be many times more difficult to implement.

Pychess is also good, but only for very amateurish use; it lacks many basic features that a chess programmer needs such as setting up engines from GUI, setting engine options, etc. I think the project has not many developers.

So linux is still waiting for a free mature chess GUI.

Rasjid.

[Don]

Hello,

Muller commented that it is 10x or 100x more difficult to write a chess GUI from scratch than it is to write a chess program.

I don't really agree with this, but I understand what he is saying. Basically you can put as much time and effort as you want into either project. I can write a chess program in a couple of days but I can also write a chess GUI in a couple of days. Neither would be anything more than the most basic thing.

To build a really high quality GUI would involve an enormous amount of time to do right, but so would a top quality chess program.

I think it depends on what detail features we want. Pychess GUI is one written from scratch and I think it is not very much more difficult than writing a full feature UCI chess program. It depends on whether a programmer is familiar with graphics programming.

It is ok if we only want UCI compatibility; but for UCI + xboard protocol as in the xboard attempt, it would be hellish. I doubt anyone would find it entertaining to think of writing from scratch a new replacement for xboard. Even getting an updated version of the xboard protocol would be difficult as compared to the single file UCI protocol. Add to the mess about attempting backward compatibility so that old xboard engines may still run!

For me, the only difficulty (special or unusual features aside) in writing a chess GUI is the graphics programming part - the glade/GTK+ widgets and cairo graphics part and they are more difficult than plain C/C++. If somehow I have a partner who can do for me the UI outlines and give me the widget features I want, I think it is not too difficult for me to put in the codes for the callback functions. As an example, the earlier codes I posted is an outline for the menu 'Games->new->start' to run a new game between two UCI engines. The difficult part is to implement the UI for users to edit preferences, options,to set up new engines, etc. Or maybe my implementation of a chess GUI is fit only for cavemen!

Tell me about taking over Tim Mann's xboard and to maintain or improved on it - impossible! I think it can end only in a mess and not much benefits to users can come from it no matter how much effort is put in; if enough of effort is put in to make it really good, it is like reworking it in assembly which is 10x or 100x more difficult.

Taking over the old xboard codes have too much of constraints and it is the antiquated widget library used that would posed the greatest difficulty. Modern unix programs all make use of the latest graphics library. As an example, if we need to select/save a file, the file tree would pop-up and we could easily select what we want. Only GTK+ and QT have such easy to used standard widgets. So in my experimental GUI, I could get out the initial chess position. I could resize it using my mouse and it scales automatically as auto scaling is a feature for some standard widgets. xboard cannot resize the board; I think it also cannot flip the board from menu (or I miss it). This is not to point out the failure of Muller. I myself have to do some work before I could repaint the board when the user chooses Board->Option->FlipBoard. I think with the xboard code, it would be many times more difficult to implement.

Pychess is also good, but only for very amateurish use; it lacks many basic features that a chess programmer needs such as setting up engines from GUI, setting engine options, etc. I think the project has not many developers.

So linux is still waiting for a free mature chess GUI.

Rasjid.