Linux Chess GUI that's good for engine matches/tournaments

[hgm]

Don't you think that sounds completely different now to what you said first?

Cutechess-cli is so much better for tourneys like xboard.

No, because i wrote in this message:

This is an alternative way to do the same things.

Just take one statement without the message context makes the world easy of course! And again: It was my personal experince!

Regards
Daniel[/i]

'Alternative' is not the same as 'equivalent'. Of two ways for achieving the same thing one can be easy, the other hard, one can be a pleasure, and the other can utterly suck. In the quoted post you voice an opinion about the relative quality of these alternatives, and it is that opinion I asked you to substantiate for the benefit of the readers. So far you failed to do much of that, though.

That seems a quite natural request to me, and certainly no reason to go ballistic over.

Note that you brought this inquiry entirely on yourself; if you would just have wanted to point out it was an alternative, you could have done it perfectly well without the sentence "Cutechess-cli is so much better for tourneys like xboard" (presumably meaning "Cutechess-cli is so much better for tourneys than xboard", now that English grammar has also become a subject of this discussion).

[ilari]

This thread got quite silly.

Cutechess-cli was never meant to replace a GUI, and I wouldn't recommend it to people who want to play chess or watch chess. At the moment XBoard is the most capable GUI on Linux.

We plan on shaking things up a bit with the upcoming cutechess-gui however...

[Daniel Mehrmann]

'Alternative' is not the same as 'equivalent'.

Right and i never used the word "equivalent". I used always "Alternative"

Of two ways for achieving the same thing one can be easy, the other hard, one can be a pleasure, and the other can utterly suck.

Right again, but it's depends on the user what is "easy" or "difficult". And if a user choose the more complex way, because, just for example the user wants more options and possibilities, easy would be wrong target.

In the quoted post you voice an opinion about the relative quality of these alternatives, and it is that opinion.

I never talked about quality! I could do that right now...but we're talking only about tourneys in this case and it's not the topic of this thread.

I asked you to substantiate for the benefit of the readers. So far you failed to do much of that, though.

Quote myself:

And if you think you do that for all other "readers" in this thread - Who allows you to speak for them ? Why do you think they think like yourself and they are interested in the same manner in questions and answers ?

That seems a quite natural request to me, and certainly no reason to go ballistic over.

Note that you brought this inquiry entirely on yourself; if you would just have wanted to point out it was an alternative, you could have done it perfectly well without the sentence "Cutechess-cli is so much better for tourneys like xboard" (presumably meaning "Cutechess-cli is so much better for tourneys than xboard", now that English grammar has also become a subject of this discussion).

I think we live in a free world and it should be allowed to say what I prefer based on my experience. I don't need to present any reasons, because it a suggestion and everyone should make own experience with it. It's a matter of taste if someone like this way or prefer a mouse gui.

[hgm]

Quite so. But this was not sufficiently clear in your original post, which could create the false impression on the unwary reader that what you suggested would be a preferable solution for the general public (over XBoard), rather than a very exotic personal preference on your part. But your last remark does make that sufficiently clear, so everyone can be happy now.

[hgm]

We plan on shaking things up a bit with the upcoming cutechess-gui however...

I am looking forward to that.

If cutechess-gui on Linux needs the engines to be 'registered' with it for use, would you support the 'plugin standard' for that (based on the .eng files included in the engine package, placed in the system's plugins directory for the appropriate protocol)?

Would it be an idea to alsoprovide interchangeability in other areas, inparticular graphics? So that the GUIs could automatically use each other's piece and board images? Packaging and distribution of 'board themes' is an issue we addressed in XBoard only recently, (in version 4.9), which has not yet fully crystallized. XBoard uses SVG images for the pieces.I suppose in cutechess-gui you would also go for SVG. I do like the idea of having packages that could be used for multiple GUIs. To make this a reality it might be necessary to make the unpacking and installing such packages a GUI function.

[ilari]

We plan on shaking things up a bit with the upcoming cutechess-gui however...

I am looking forward to that.

If cutechess-gui on Linux needs the engines to be 'registered' with it for use, would you support the 'plugin standard' for that (based on the .eng files included in the engine package, placed in the system's plugins directory for the appropriate protocol)?

Currently cutechess-gui has an engine management dialog where one can setup and configure engines by selecting the executable. There's no support for a plugin standard, but if XBoard implements it, I would also like to implement it.

Would it be an idea to alsoprovide interchangeability in other areas, inparticular graphics? So that the GUIs could automatically use each other's piece and board images? Packaging and distribution of 'board themes' is an issue we addressed in XBoard only recently, (in version 4.9), which has not yet fully crystallized. Xboard uses SVG images for the pieces.I suppose in cutechess-gui you would also go for SVG. I do like the idea of having packages that could be used for multiple GUIs. To make this a reality it might be necessary to make the unpacking and installing such packages a GUI function.

Yes, we're also using SVG - a single file that contains all chess pieces for all supported variants. We don't have board themes and the number of variants is much more limited than Xboard's, so the current situation suits us fine. Anyone can of course use our pieces in their own projects as long as they obey the Creative Commons license.

[hgm]

Currently cutechess-gui has an engine management dialog where one can setup and configure engines by selecting the executable. There's no support for a plugin standard, but if XBoard implements it, I would also like to implement it.

That is great. XBoard at startup currently scans the directories /usr/(local/)share/games/plugins/xboard/ and /usr/(local/)share/games/plugins/uci/ for files *.eng, which currently contain only the engine command (possibly with a directory specification for (non-compliant) engines that need to run in a specific directory), to check if there are any engines on the system it has not seen before. In the future a line in these *.eng files that lists the variant groups that the engine plays could be used to configure GUIs which engines to ignore and which to install. At the moment I cannot imagine much other information about the engine that would be useful to have there. (Perhaps a list of known non-compliancies so that the GUI can automatically invoke work-around options for them when the engine gets loaded? E.g. whether the engine reports scores with the wrong sign, or (for UCI) whether it supports searchmoves.)

I have not really decided on how to handle adapters yet. In XBoard the auto-registration of UCI engines should really be dependent on the presence of Polyglot or UCI2WB. Currently it auto-registers them unconditionally, though. While it would never look at USI or UCCI engines (which should have their own plugin directories). It would be better if the Polyglot package dropped a .eng file in the .../plugins/xboard directory that would announce in as a adapter for UCI engines, and that XBoard would then only scan the .../plugins/uci directory in response to finding that. Then UCI2WB could similarly drop a .eng file that announces it as uci, ucci and usi adapter, making XBoard also scan the directories for these protocols. It is bit tricky to arrange it so that it doesn't matter whether the engines or adapters for them were installed first, however.

Yes, we're also using SVG - a single file that contains all chess pieces for all supported variants.

I did not even know that it was possible to have multiple independent images in a single SVG file. Is there a specific advantage of packing them in a single file compared to having a separate file for each piece type?

We don't have board themes and the number of variants is much more limited than Xboard's, so the current situation suits us fine. Anyone can of course use our pieces in their own projects as long as they obey the Creative Commons license.

Note that with 'board themes' I also meant the piece representation (e.g. Alpha, Meridia, Leipzig...). Do you mean you will only support one (possibly variant-dependent) representation of the pieces?

[ilari]

That is great. XBoard at startup currently scans the directories /usr/(local/)share/games/plugins/xboard/ and /usr/(local/)share/games/plugins/uci/ for files *.eng, which currently contain only the engine command (possibly with a directory specification for (non-compliant) engines that need to run in a specific directory), to check if there are any engines on the system it has not seen before. In the future a line in these *.eng files that lists the variant groups that the engine plays could be used to configure GUIs which engines to ignore and which to install. At the moment I cannot imagine much other information about the engine that would be useful to have there. (Perhaps a list of known non-compliancies so that the GUI can automatically invoke work-around options for them when the engine gets loaded? E.g. whether the engine reports scores with the wrong sign, or (for UCI) whether it supports searchmoves.)

I have not really decided on how to handle adapters yet. In XBoard the auto-registration of UCI engines should really be dependent on the presence of Polyglot or UCI2WB. Currently it auto-registers them unconditionally, though. While it would never look at USI or UCCI engines (which should have their own plugin directories). It would be better if the Polyglot package dropped a .eng file in the .../plugins/xboard directory that would announce in as a adapter for UCI engines, and that XBoard would then only scan the .../plugins/uci directory in response to finding that. Then UCI2WB could similarly drop a .eng file that announces it as uci, ucci and usi adapter, making XBoard also scan the directories for these protocols. It is bit tricky to arrange it so that it doesn't matter whether the engines or adapters for them were installed first, however.

Have you documented these engine registrations and plugins somewhere and are there already engines that use them? It doesn't sound that complicated to implement for GUIs.

I did not even know that it was possible to have multiple independent images in a single SVG file. Is there a specific advantage of packing them in a single file compared to having a separate file for each piece type?

We're using Qt's QSvgRenderer interface which is really convenient for multiple elements in a single SVG: http://doc.qt.io/qt-5.6/qsvgrenderer.html
All we need to do is give each element an id - eg. "wpawn" or "bknight", load one file, and let the pieces render themselves by calling the renderer's render method.

Note that with 'board themes' I also meant the piece representation (e.g. Alpha, Meridia, Leipzig...). Do you mean you will only support one (possibly variant-dependent) representation of the pieces?

Version 1.0 will definitely support only one set, but it would be trivial to add themes later.

[JoshPettus]

I did not even know that it was possible to have multiple independent images in a single SVG file. Is there a specific advantage of packing them in a single file compared to having a separate file for each piece type?

We're using Qt's QSvgRenderer interface which is really convenient for multiple elements in a single SVG: http://doc.qt.io/qt-5.6/qsvgrenderer.html
All we need to do is give each element an id - eg. "wpawn" or "bknight", load one file, and let the pieces render themselves by calling the renderer's render method.

Does it perform better to have it parse a single file in such a manner then the loading of separate files? I would think it would be a bunch of work to create such files: interferes with maintainability and the general ease of creation. But then I have enough trouble with inkscape as it is, and complicated svg images are a bear. I fear it would be more difficult to make additional sets then it really needs to be. Just because you can doesn't mean you should.

[kbhearn]

single file has the advantage of ease of distribution/configuration. you just have to point the gui at a single file. i assume most graphics editors would allow you to use a layer per piece and assign custom ids to the layers, but if not you could always use text editing to combine seperate files later.