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.
Actually I may not know what a high quality chess GUI is as I don't have any of those commercial ones. I was familiar with winboard years ago when I was using Windows. But whether winboard or Xboard, I only use it to do 'testing' for my Cowrie chess program with various chess partners. My secret testing scheme is two games from the initial positions with changed sides! If it beats Komodo or Houdini 2-0 at 60 moves per min, it is enough; no need of 30,000 games as someone routinely is doing to confirm a gain of 15 elo.
What I know is Muller would have a very hard time with Xboard.
As for a chess engine, mine is of a 'high' quality as it has implemented almost all methods publicly known in chess programming - only a part of the ELO is truncated. With 15% of the lines of codes as assert(), and none is trigered in a 100 random games, I can vouch that Cowrie chess has no bug and of top quality
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.
Actually I may not know what a high quality chess GUI is as I don't have any of those commercial ones. I was familiar with winboard years ago when I was using Windows. But whether winboard or Xboard, I only use it to do 'testing' for my Cowrie chess program with various chess partners. My secret testing scheme is two games from the initial positions with changed sides! If it beats Komodo or Houdini 2-0 at 60 moves per min, it is enough; no need of 30,000 games as someone routinely is doing to confirm a gain of 15 elo.
We generally do not test to measure the amount of the gain or loss, only to attempt to confirm or prove (empirically) there is a gain.
I guess I don't understand your secret testing methodology of being able to prove there is a gain with only 2 games. If there is such a thing it would be a most incredible find.
What I know is Muller would have a very hard time with Xboard.
As for a chess engine, mine is of a 'high' quality as it has implemented almost all methods publicly known in chess programming - only a part of the ELO is truncated. With 15% of the lines of codes as assert(), and none is trigered in a 100 random games, I can vouch that Cowrie chess has no bug and of top quality
Rasjid.
Capital punishment would be more effective as a preventive measure if it were administered prior to the crime.
Chan Rasjid wrote:From polyglot readme :
To use PolyGlot with XBoard, you would type something like this:
> xboard -fd 'ini_dir' -fcp 'polyglot engine.ini'
Well, this is good advice if the polyglot binary is in /usr/games, where it would normally be installed from the Debian binary package (and which is in you path). It is no good, however, when the Polyglot binary is in the engine (-fd) directory.
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"
And the file /home/rasjid/chess/polyglot/polyglot really existed and had execute permission? (And how about /home/rasjid/chess/polyglot/fruit.ini ?)
I googled and there were some posts elsewhere where others too faced the same problem:
...
No, this really is a completely different problem. This discusses what happens when people do not invoke Polyglot explicitly at all, but only mention the engine binary with a -fUCI or -sUCI option.
Have you tried that, btw? (xboard -fcp fruit -fUCI)? Wen polyglot and fruit are installed on your Linux in a compliant way, this should work withut problems.
Chan Rasjid wrote: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.
Actually the widgets of XBoard never caused me too much of a problem, and the latest XBoard code is now in a state where you are almost completely isolated from the widgets. You can add controls to existing dialogs, or complete new dialogs, without ever interacting directly with any widgets. You just declare a list of control descriptors (name, type, corresponding variable) similar to that build from the options WB or UCI engines send to the GUI. The latest development version also uses such a list to define a convenient file-browse dialog.
xboard cannot resize the board; I think it also cannot flip the board from menu (or I miss it).
You missed it; it has been able to flip the board for as long as I know it (so at least since 4.2.7). XBoard can indeed not resize the board (only WinBoard can). It would not be difficult at all to add that now, however. It already resizes the board window when you switch between variants with different board formats (e.g. to 9x10 for Xiangqi). Initially I stayed away from sizing the board, because it requires loading of a new set of piece bitmaps, something the original code only did at startup. But by now I have isolated all code that should be executed to change piece set, and located it in subroutines that can be called at any time. This for the purpose of changing to an external collection of piece bitmaps in the View->Board menu dialog. Not freezing the board-window size, so it could be re-sized with the mouse, and in response calculate new drawing sizes, would not be a very big deal. It is just that I hardly ever code specifically for XBoard, as I am rather Windows oriented.
Perhaps he's complaining about it from a user standpoint. Xboard's widgets are ugly as sin. Even the menus have text that's difficult to read (no anti-aliasing). If someone were to take up xboard, replacing the visual components with modern gui parts is an understandable priority. At which point, might as well start fresh.
Most of these things are actually configurable, and having clearer menu texts could be simply a matter of picking another font.
BTW, there already exists a GTK version of XBoard (one of the branches in the GNU repository), but it is not completely finished. It does make use of SVG pieces, and the board can be resized. Since I know nothing about GTK, I never did any coding on it, but it is there.
Porting to other widget sets should be extremely easy. I refactored the XBoard code to condense the amount of Xaw/X11 code to almost nothing, where the remaining Xaw/X11 code is almost completely free of any 'business logic'. This as preparation for making an Android port. Starting from this code, it should be rather trivial to port it to any other widget set or platform, for someone who had any knowledge of that widget set. It should be about 100 times easier than starting from scratch, and in my estimate should be doable in just a few weeks.
My mistake again - my apology. I compiled polyglot from source and it is now ok.
The command works :
xboard -sd '/home/rasjid/chess/polyglot' -scp './polglot fruit.ini'
The proplem is the binary polyplot_linux that I downloaded somewhere and I was careless; linux compiles are very sensitive to distros, 32/ 64 bits and processors. My arch linux official package now has only xboard and nothing else. I think Debian has many others like polyglot, fruit, stockfish, hoichess, etc.
On the quality of xboard, a new rewrite from scratch would still be the best
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.
There are two kinds of people in this world: those who are writing a chess GUI and those who think that writing a chess GUI would be easy. When I started to work on Cute Chess I thought it would maybe take a few months. Now, 4 years and over 50k lines of code later, I can say that it takes way longer than expected. But if you do it right, it can also be very rewarding.
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!
I actually didn't find it too difficult to support Xboard in the GUI. It's true that supporting old protocol 1 engines is a huge pain, but otherwise I think Xboard support is easier to implement than UCI. The most important thing is good module/class design and good abstractions that allow you to add support for new protocols without changing any existing code.
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.
I wouldn't be able to do it either, but I think HGM has proved that it's in fact not impossible to take over Xboard development and improve it further.
ilari wrote:
There are two kinds of people in this world: those who are writing a chess GUI and those who think that writing a chess GUI would be easy. When I started to work on Cute Chess I thought it would maybe take a few months. Now, 4 years and over 50k lines of code later, I can say that it takes way longer than expected. But if you do it right, it can also be very rewarding.
I could have underestimated the work of writing a chess GUI; probably mine would be of a type what Don said could be done in three days - it would be one year for me as I would have to fumble with Glade/GTK+ and cairo graphics.
I think some tried and did not complete the project to their satisfaction - the Biglion author Matheus. There are one or two more Linux chess GUI besides pychess, but their features are still the rudimentary few that cannot be an alternative for xboard.
My complaint is that the look and feel and the ease of use of xboard cannot be compared to the newer graphics programs; eg the graphics linux terminal, gedit or even pychess. They are a breeze to use and configure. A new xboard done from scratch would be a different story.
Chan Rasjid wrote:My complaint is that the look and feel and the ease of use of xboard cannot be compared to the newer graphics programs; eg the graphics linux terminal, gedit or even pychess. They are a breeze to use and configure. A new xboard done from scratch would be a different story.
Are you sure that this is not merely because of the way you use it? From the commands you posted I noticed that you explicitly invoke Polyglot, and configure it by using a fruit.ini file. I imagine that configuring gedit would also be an extreme pain if you would try to locate the hidden user preference files for it, and edit those. But no one in his right mind would try to configure gedit that way, of course.
What seems needed is not so much re-doing XBoard from scratch, as well as re-doing its users from scratch.
