Elements of the ULTIMATE Chess GUI?

[hgm]

In PyChess when "New" button pressed in Manage engines window it opens a standard file selection dialog, and when you select your new engine it try to detect (in the background) automatically the protocol sending "uci" first. If it not responds with "uciok" in a reasonable time it will be xboard. All in all most of the time adding a new engine is done by only selecting it from the file system.

I consider that an inacceptable method, because some engines support both UCI and CECP, and then you would automatically run those as UCI, which would incur loss of functionality...

[hgm]

It's blatantly obvious to anyone with even rudimentary competence in the fields of usability and GUI design. For your remarks with Arena, I never said it is great, it actually isn't. It's just not horrible, that's all it takes.

Just more bashing. Nothing even remotely constructive.

It was you who started to talk about non-chess stuff in a thread about the ultimate chess GUI.

It was you who objected against the presence of a "Force use of current variant" checkbox in the Load Engine dialog, and qualified it as "a load of stuff that should not even be there"...

It doesn't because lots of settings were only available via command line switches. That's total garbage for a GUI, and Linux is the only place where such garbage had any chance to survive longer than a snowman in a sauna.

That was in a much later stage. Originally these settings did not exist at all. Then they were added because of the development of WinBoard (which did use menus to set them, and command-line options to store them in the persistent settings file). That the command-line options also worked in XBoard was just a WinBoard spin-off, and not by design.

[gbtami]

In PyChess when "New" button pressed in Manage engines window it opens a standard file selection dialog, and when you select your new engine it try to detect (in the background) automatically the protocol sending "uci" first. If it not responds with "uciok" in a reasonable time it will be xboard. All in all most of the time adding a new engine is done by only selecting it from the file system.

I consider that an inacceptable method, because some engines support both UCI and CECP, and then you would automatically run those as UCI, which would incur loss of functionality...

Users can change UCI/CECP later if engine supports both, so there is no loss of functionality at all. They just get a usable default setting which is working out of the box.

[Fulvio]

So the question IMO is "which info does the user has to supply often to fully complete the task (of getting the new engine running), and which info is so optional that it would almost never need to be given?".

Finally.
Let me quote my first post:

For example he is right about the engine's parameter field: many engines do not need it and should not be showed by default.

[hgm]

Users can change UCI/CECP later if engine supports both, so there is no loss of functionality at all. They just get a usable default setting which is working out of the box.

Well, having to change later seems worse than having them select it in the first place. It is a very major flaw in all these protocols that the engines do not start announcing spontaneously what protocol(s) they support.

Perhaps your method can be adapted by sending 'xboard' and 'protover 2' first, and then, if there is no quick response, try if 'uci' evokes one.

[hgm]

So the question IMO is "which info does the user has to supply often to fully complete the task (of getting the new engine running), and which info is so optional that it would almost never need to be given?".

Finally.
Let me quote my first post:

For example he is right about the engine's parameter field: many engines do not need it and should not be showed by default.

There is nothing 'final' about it. For one this has been the design principle of WinBoard all along. And we just don't agree on what the threshold should be to qualify for the inclusion in the Load Engine dialog. 'Most engines' can be as little as 51%, and if 49% would need it, I would want it there. I don't want to have to go to another dialog that I would almost certainly not need otherwise in nearly half the cases. I would not even want that in 10% of the cases. So my opinion was (and is) that enough engines need it to make hiding it in some other dialog a bad design.

To this a nasty technical problem adds: the Engine Settings dialogs are not functional before communication with the engine is established. And any command-line arguments would have to be known before you even can start the engine. So starting of the engine would somehow have to be delayed until the GUI can get hold of the command-line arguments. And the GUI cannot know whether these are necessary, so it now would have to do that for every engine (while, as you say, most engines would not need it).

So you opened a can of worms, and for what? To avoid a noob user from being distracted in finding the 'browse' button for the executable, only to be forced to present it to him one dialog later? How stupid do you think the average user is, that it should be impossible to deter him from using an occasionally needed text entry by other means? Are we developing UIs for Tourette patients now? There are plenty of possibilities that I would prefer over locating that text entry in another dialog, which should cause absolutely no hardship on any noob user with an IQ > 10. Like making an extra checkbox "Unusual engine that needs extra settings before it can be started", and only enable the command-line parameters text entry when that checkbox gets ticked.

I often use that text entry. Just like I often want to associate GUI settings with a particular engine, and often want to install engines that do use and that do not use the GUI book.

[Fulvio]

How stupid do you think the average user is, that it should be impossible to deter him from using an occasionally needed text entry by other means? Are we developing UIs for Tourette patients now?

Take a breath and calm yourself.
No one ever talked about intelligence or the lack of it.
We are talking about knowledge, and in particular knowledge that users do not WANT to be forced to learn (about chess protocols, about how your program works internally, why some engines need parameters or a directory, etc.).

[gbtami]

"Well, having to change later seems worse than having them select it in the first place."

Why?

"Perhaps your method can be adapted by sending 'xboard' and 'protover 2' first, and then, if there is no quick response, try if 'uci' evokes one."

Whis is this better than the opposite?

[hgm]

The argument for not wanting a UCI/WB choice was that the user should not be bothered to know about UCI or WB. To have him change it later would need him actively go hunting for a dialog where he can change this. Which would require him to know for this particular engine that it is both WB and UCI, or why else would he even try?

I would prefer CECP as a first choice because it is more functional. It seems wrong to automatically start dual-protocol engines in the inferior mode that limits their capabilitieis by default. It is true that WB v1 engines would not respond to the 'protover 2' probe, but it is very unlikely that any dual-protocol engine would not support WB v2. (And there is really no excuse for doing that.)

[Evert]

"Perhaps your method can be adapted by sending 'xboard' and 'protover 2' first, and then, if there is no quick response, try if 'uci' evokes one."

Whis is this better than the opposite?

I can't speak for the general case. For SjaakII, CECP should be preferred to UCI, both because it receives more testing, but also because it has better variant support. However, to fully benefit from that the GUI should also support CECP custom variants.

It is a useful thing that the "uci"/"uciok" handshake exists. It is a shame that there is no "xboard"/"xboardok" equivalent that works reliably. As such, you can detect reliably whether an engine claims to support UCI, but you can only guess if an engine seems to support CECP...