Elements of the ULTIMATE Chess GUI?

[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...

[hgm]

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.).

Not wanting to learn all that should not really conflict with the presence of an extra facility for people that do want to learn. (Well, it requires them to learn how to read, so they can understand a "hands off" sign...).

I agree it is very unfortunate there do exist engines that need command-line parameters, or interpreters that need the engine source as command-line parameter, just as it is very unfortunate that UCI (and even more so USI, and all those other crimes against humanity) exist but it is a fact of life that they do exist. So users must decide where their priorities lie: either they 'learn' that README files are actually intended for reading before you start blundering around, or they should just stay away from those engines. I should not make that choice for them, and I would never sacrifice the interests of the group that is prepared to learn how to use the more difficult engines to indulge the group that is not prepared to make any effort whatsoever.

I still don't see how it would harm the interest of the ignorant bunch in any way if the dialog they use to select a new engine from contains one or two controls only useful for the 'expert user', as long as it is clearly indicated they are optional and should not be used unless a README file requested it. People that are so intolerant that they object to my menu card having pork on it because they only like beef are not welcome in my restaurant!

[hgm]

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...

Well, "protover 2" / "feature done=1" is the CECP equivalent. The problem is WB v1, and in particular poorly implemented WB v1, because fully compliant WB v1 engines are expected to answer to "protover 2" with "Error (unknown command): protover". If WB protocol is so poorly implemented, it would be likely preferable to run such engines under UCI, if they can. (Which, as I said, seems extremely unlikely.)

[gbtami]

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.)

I think you missed my point. In Xboard/Winboard if a user downloads a new engine (for example the latest Stockfish) and he wants to play with it he can select it pressing ... on "Load New 1st Engine" dialog, select the binary then push Ok. Then he takes hes first move. And he is waiting... Forever because Stockfish doesn't starts to play. Because Xboard expects to click UCI. But user knows nothing about this.

My point is why not provide useful default (UCI clicked in this case) if we can introspect engines for supported protocol. (If it support both UCI and Xboard you can select Xboard as the default if you think UCI is inferior.)