Winboard/Xboard spin off; was Arena 3.5

[hgm]

As I use lately a Linux system I was forced to switch to Xboard. It might be OK for excessive engine testing, but in point of usability Arena is much easier. If you complain about 2 CPU parameters in Arena, think for example about the 6 different book options for UCI engines in Xboard:

Common Engine settings
1. Use GUI Book
2. Engine 1 has own book
3. Engine 2 has own book
Engine settings
4. Own Book
5. Polyglot book
Load Engine
6. Must not use GUI book

The difference is that if you report things you don't like on XBoard, you won't have to deal with a bunch of useless morons that start to call you names. On the contrary; chances are that it will be fixed the next day, and at the very least you will receive an explanation why you are overruled. I also see no logic in the idea that something in Arena should not be considered a bug or not be reported just because there exists other software that has worse bugs. This is a thread where the OP invited us to report Arena bugs. Not XBoard bugs.

I admit the book situation in XBoard is a bit baroque, and the naming of the options perhaps not the clearest. "Use GUI Book" (1) should perhaps be called "Book file valid", and in practice it is very handy to have such a checkbox. It allows you to temporarily disable the book, without losing the (possibly longish) path name, so that you don't have to re-type / re-browse for it when you want to switch it on again.

There is a GUI book, which can be used by all engines, or engines can have their own book. I don't think that is in any way uncommon: some testers do not want engines to use their own books, but want to play all engines from a shallow book with only balanced lines. And some testers do allow own books, but allow engines without own book to use a GUI book to force some non-determinism on them. So you have to be able to switch the engine's own book on and off on a per-engine basis (2, 3).

The checkbox in the Load dialog (6) is for deciding if the engine should be installed with own book or GUI book as default, so that each time you would recall that engine, the "own book" checkboxes would get the desired value automatically. The "own book" checkboxes themselves are just for the current session, and won't affect the way the engine is installed. (This is a design choice; it could be made such that any setting change ever made when running an engine would persist to later sessions with that engine, but my guess is that most people would not want that.) Perhaps (6) should indeed be renamed to better indicate it is a default setting for something else to be installed with the engine.

The tricky point is the Engine Settings dialog (4, 5). Polyglot is not only a protocol adapter, but can handle book on behalve of a UCI engine as well. The question is whether this capability should be made accessible to the user through the GUI. Personally I would say that there is little need for this, now engines that do not support book (which is most UCI engines) can use the GUI book. But I am pretty sure it would cause an outcry if I would alter Polyglot to no longer offer this option. So what can I do? It isn't how I would have designed it, but now it exist, people want to keep it. They want to be able to run UCI engines that do not support books with private books handled by Polyglot.

I did not even try to find out which book options I have too use since I don't do serious testing anymore.

For Analysing Scid is my choice, for my own games and internet play PyChess. I use Xboard only for enginematches, but a match under Arena is set up in half the time.

I heard that remark before, but without a more detailed description of what exactly makes it so cumbersome there is very little I can do to improve it. For me setting up a tourney with XBoard is lightning fast, and it is hard for me to imagine how it could be faster. I just click the participants from the listbox of installed engines, sometimes click one or two checkboxes (e.g. whether I want every opening played twice with reversed colors, or not), then OK, and the runs. (I usually run at the same TC; if not, I would have to set that first.) Hard to imagine how I could make it work without having to click the participants, which was what nearly took me all the time. And for people that really do play huge gauntlets with always the same engines, there always is the possibility to call up the latest such tourney through a Browse button, and press 'clone tourney' and OK to run with the same parameters. (Or change the settings you want changed first.)

So it doesn't seem to waste any mouse clicks. If you know a faster way, I am all ears...

A few Xboard powerusers probably use a tournament manager, but for normal users this is too complicated.

Under Windows I used Arena for all kind of things though ChessGUI came up for engine tournaments and Scid for database functions. But Arena is less specialized than Winboard.

So all GUI's have their strength and weaknesses, this condescending statements by whomever are really annoying.

[Alexander Schmidt]

The difference is that if you report things you don't like on XBoard, you won't have to deal with a bunch of useless morons that start to call you names.

Oh yes, those morons are everywhere

Try to ignore them.

I admit the book situation in XBoard is a bit baroque,

Thanks for the explenation. This is really tricky and hard to understand for a part time Xboard user

I think the Polyglot book options in the engine settings menu are fine. At this point I know that I can chose the own book or a polyglot book.

For me setting up a tourney with XBoard is lightning fast, and it is hard for me to imagine how it could be faster.

Don't get me wrong, as I wrote likely one with experience can do it fast. I think the main difference to other GUIS's which confuses people a little is the fact that you have different options to set up before creating a tournament: If you want to set up a frc match you first have to load a frc engine and then select the variant. Then you have to open the time control window and chose a timecontrol. In standart chess you have to select the opening book first. All this has to be done before you open the tournament window. If you want to change the book, or if you want to check if the correct book is selected, or if the engine you want to select has the correct value for e.g. threads you have to cancel the creation of the tournament, and start from the beginning.

In general I would expect all important parameters of a tournament in one dialogue, including variant, timecontrol, book options, adjudicating options. It would be nice if the dialogue box wold remember the options in case I want to change the book, or an engine option during the tournament creation process. So far I have to redo everything when I interrupt the creation of a tournament.

Sometimes it happens that a tournament or an engine is set up in a wrong way and a tournament-restart option would be nice.

It happened that one engine ran out of time and the tournament didn't go on.

It happened that I used the engine output window and the engines became very slow and lost on time.

And of course the crosstable is a missing feature. The docs relegate to other applications but I was not able to find one that is able to handle the PGN of variants.

I was a little bit lazy with reports of such problems since I stopped serious engine tests.

[hgm]

OK, thanks for your feedback.

Don't get me wrong, as I wrote likely one with experience can do it fast. I think the main difference to other GUIS's which confuses people a little is the fact that you have different options to set up before creating a tournament: If you want to set up a frc match you first have to load a frc engine and then select the variant.

Ah, yes, I must admit the TM is not primarily optimized for variants. A slight shortcut here would be to start XBoard without engine, ("xboard -ncp", or ticking "View games" in the WinBoard startup dialog). The variant selection dialog is already so large, that it would be rather inconvenient to combine that with all the other tournament settings in one dialog.

Then you have to open the time control window and chose a timecontrol. In standart chess you have to select the opening book first. All this has to be done before you open the tournament window. If you want to change the book, or if you want to check if the correct book is selected, or if the engine you want to select has the correct value for e.g. threads you have to cancel the creation of the tournament, and start from the beginning.

OK, I see your point. The need to restart from the beginning defintely was a design flaw that I had not foreseen. But this problem has been addressed since version 4.7.0: there now is a 'continue later' button in the Tournament dialog that allows you to close it, do other things, and then re-open it, and find all settings as you had left them.

In WinBoard it was already possible to temporarily 'escape' to the Time Control dialog or the Common Engine dialog (to set Book, Hash, CPUs), without the need to close the Tournament dialog, through buttons in the latter. That makes it hardly more difficult than when the controls of those dialogs had been in the same dialog, (which IMO, would overload the dialog with too many controls), and exactly as many mouse clicks as when, for example, the extra controls had been hidden in a tab of the Tournament dialog. I think the main inconvenience that bothered you (correct me if I am wrong) was that you would lose already entered data when you were forced to leave the dialog.

In general I would expect all important parameters of a tournament in one dialogue, including variant, timecontrol, book options, adjudicating options. It would be nice if the dialogue box wold remember the options in case I want to change the book, or an engine option during the tournament creation process. So far I have to redo everything when I interrupt the creation of a tournament.

Unfortunately XBoard does not have the buttons yet to pop up TC and Common Engine without closing the dialog. This is high on my wish list, but due to the way in which XBoard creates dialogs, hard to do. The 'continue later' button should already relieve most of the pain, though. I will work harder on making 'dialogs within dialogs' possible in XBoard.

Sometimes it happens that a tournament or an engine is set up in a wrong way and a tournament-restart option would be nice.

I don't quite get this. You mean a tournament where some games have already been played, where you would want to discard those games, and replay everything? That is basically the same as starting a new tournament with exactly the same parameters. The easiest way to do the latter is select the 'tournament file' of the tournament you want to cancel, using the Browse button for tourney files in the dialog, press 'Clone tourney' to copy all its parameters, possibly change the file for the saved games (to not get them in the same file as the games you want to discard, unless you had already deleted that file), and press 'OK'.

It happened that one engine ran out of time and the tournament didn't go on.

Hmm, this sounds like a serious problem. I suppose that you did have the Auto-Flag option on. (Otherwise it would be natural.) My guess is that it would be caused by a hanging engine that had to play two games in a row. XBoard waits until the engine reports it is ready for a game, but if an engine hangs unresponsive, it will never report ready for a new game.

XBoard has options that could be used to force starting a new engine process and discarding the old. Perhaps I should force it into that mode during a tourney. (But if 'Games per pairing' is 1, this is already automatic.) The downside is a little time loss between games when an engine plays two games in a row (e.g. because it again has to initialize its tablebases). What is worse is that in cases where the old engine is hanging, it usually also is using CPU, and discarding it in favor of a new engine process might not terminate it. So it could still be severely affecting the tourney, even though the latter continues, by eating recources during all following games.

So this is a really tough problem. For WinBoard, at least, as on Windows killing processes does not seem to work reliably. (The case you describe must heve been with WinBoard!?) In XBoard such a thing should never happen with 1 game per pairing, or otherwise forcing engines to unload after a game, as XBoard kills discarded engine processes, and killing on Linux is reliable.

It happened that I used the engine output window and the engines became very slow and lost on time.

This points to a bug I have never noticed before. Was this in XBoard or WinBoard?

And of course the crosstable is a missing feature. The docs relegate to other applications but I was not able to find one that is able to handle the PGN of variants.

Oh, in my ignorance I thought that almost any such utility would do that, as in principle they would only have to look at the PGN tags (players and result tag), not at the moves. I did actually write such a cross-table generator that delivers simple ascii output. Perhaps I should bundle it with WinBoard and XBoard. I will give it a thought. It has always seemed best to me to have a separate program for examining PGN files as cross table, rather than let the GUI display it, because you also want to be able to look at cross tables for tourneys that have already finished.

[Milos]

Unfortunately XBoard does not have the buttons yet to pop up TC and Common Engine without closing the dialog. This is high on my wish list, but due to the way in which XBoard creates dialogs, hard to do. The 'continue later' button should already relieve most of the pain, though. I will work harder on making 'dialogs within dialogs' possible in XBoard.

Ever heard of tabs in a window??? Gee, and you get offended when ppl call your interface prehistoric.
It is as comfortable to work as Windows 3.11 (at least Windows had windows)...

[hgm]

Ever heard of tabs in a window??? Gee, and you get offended when ppl call your interface prehistoric.

Where do you get this silly notion that I would get offended. I just give a free analysis of people's character flaws.

As far as technical content, have you ever heard of Athena widgets? Apparently not...

It is as comfortable to work as Windows 3.11 (at least Windows had windows)...

How would you know?

[Milos]

Ever heard of tabs in a window??? Gee, and you get offended when ppl call your interface prehistoric.

Where do you get this silly notion that I would get offended. I just give a free analysis of people's character flaws.

As far as technical content, have you ever heard of Athena widgets? Apparently not...

Another prehistoric widget lib, why that doesn't surprise me.
I should probably ask at this point don't you know how to use Qt?

[hgm]

That is not very relevant, if I am not the one who wrote XBoard, wouldn't you say? You'd better ask the one who wrote it why he didn't use Qt.

You seem under the faulty impression that it would be my duty to fix XBoard so that you like it. I have no interest in XBoard; never use it. So why would I do that? I use WinBoard, for purposes that no other GUI can meet, and had to add a lot of features for that. Because there is a common code base those features benefit XBoard as well. But why should I do more?

[Milos]

That is not very relevant, if I am not the one who wrote XBoard, wouldn't you say? You'd better ask the one who wrote it why he didn't use Qt.

You seem under the faulty impression that it would be my duty to fix XBoard so that you like it. I have no interest in XBoard; never use it. So why would I do that? I use WinBoard, for purposes that no other GUI can meet, and had to add a lot of features for that. Because there is a common code base those features benefit XBoard as well. But why should I do more?

No I'm not under that impression. I use WinBoard also despite its drawbacks, and I don't expect you to do more. The problem is when you start defending the things which are simple hopeless to defend in these "GUI wars". WinBoard has its advantages, it's fast, it's reliable, it has a lot of features, but it is definitively not nice in terms of GUI look, and definitively not much user friendly. I understand that much of it is not your fault since you work with things that you have available, but that doesn't neglect the fact that WinBoard (and much more XBoard) needs a major rework in terms of GUI framework.

[jdart]

I use Arena, Fritz, Winboard and cutechess-cli for matches and tourneys.

Arena is one of the simplest to use IMO.

One thing I was trying hard to do recently, and failing, though was to run a match with a set of fixed starting positions from a PGN file, but also allow each engine to use its own book from that point forward.

--Jon

[hgm]

No I'm not under that impression. I use WinBoard also despite its drawbacks, and I don't expect you to do more. The problem is when you start defending the things which are simple hopeless to defend in these "GUI wars".

But I am not defending anything. This thread is not about WinBoard/XBoard. It is about Arena, and in particular to give forum scum the opportunity to launch personal attacks on someone who reports an annoying Arena bug.

Only Alexander Schmit posted an off-topic problem with XBoard here, and naturally I am interested to know the exact details, to see whether anything can be done about it. And since he is the only serious poster here, there seems little harm in such an off topic excursion. But I am not defending anything (except when you would consider pointing out that some problems in an older version already have been solved in the latest one 'defending'). Just collecting user feedback, and apologizing for some known problems not having been solved in XBoard yet, because there was no easy solution within the existing framework.

WinBoard has its advantages, it's fast, it's reliable, it has a lot of features, but it is definitively not nice in terms of GUI look, and definitively not much user friendly.

Again in the interest of collecting user feedback, to get ideas for improvement, what in your opinion makes the look of WinBoard "definitely not nice"?

I understand that much of it is not your fault since you work with things that you have available, but that doesn't neglect the fact that WinBoard (and much more XBoard) needs a major rework in terms of GUI framework.

Well, Arun Persaud and John Cheetham managed to port XBoard to GTK+, and I could integrate that with the front-end rewrite I had started for the purpose of creating an Android front-end for it (which would be useful to me). This is definitely a huge improvement over Xaw (but not completely finished), and as a spin-off has also led to nice (anti-aliased) drawing of board and pieces even in the Xaw version.

But tabs in dialogs IMO are an overrated feature, and I had no plans for using them, even if GTK+ supports them. For tabs you have to move the mouse all the time to the top of the dialog, and then back to the control you wanted to change. With a button that pops up a new dialog, you can pop it up in a location that centralizes the mouse much better. It also has the advantage that the sub-dalogs are exactly equal to those the user gets when setting the same feature directly through the menu, rather than from an already open dialog. So I think the method WinBoard uses is a more convenient way to solve the problem raised by Alexander than indiscriminately merging all dialogs into a single one with lots of tabs.