Elements of the ULTIMATE Chess GUI?

[Ferdy]

[Moderation] This message was lost due to stupidity of the moderator.

I am so sorry, Ferdinand. I must have hit the edit button when I intended to hit the quote button. Almost all of the original message is quoted in the message below, however.

H.G.

[hgm]

I still don't understand the usage of directory in Winboard. Perhaps in Xboard I don't know. The user can just locate the engine file thru the green button and it is done.

What if the 'engine' is Nodejs or the Python interpreter? The directory where you installed Python is not relevant for the engine.

It is my belief that generally idiots don't like to see options. Once it is there, the idiot would read it, try to understand it in other words become preoccupied with it. So the idea is to present options as minimal as possible. Just make the idiot press the button to locate the engine filename, press OK done.

Although this is true to some extent, I think that it this case this is an unjustified fear. There are limits even to the idiocy of an idiot. What would there possibly be to misunderstand in "must not use common book"? Even if he did not know there existed a feature like a common book, and that it is possible to make any engine use it, this sentence should alert him to that fact. And the use of the word 'common' might even guide him to the Common Engine Settings dialog when he gets the idea to change this book. I only see upsides in this case.

I prefer the words, setup and install, meaning the engine is not yet recognized by the GUI or not in the engine list. I believe idiots generally are familiar with these words.

The word 'select' doesn't seem to be an unusual word that should be out of anyone's vocabulary either. 'Install' is a misnomer; in general it means running the installer of a piece of software that you have downloaded, to put it in usable form on your disk. And actually the dialog sets up the GUI to use the engine. It doesn't set up the engine.

The statement "If specified, use it in pgn tag" is just my comment which I happen to put it there in the blank text box because of limited space in the image, it does not have to be written there. Just keep the textbox empty, and whenever the user filled it in, then use it in the pgn tag. There is no need to create a checkbox option of whether the user would want to use the nickname in the pgn tag or not.

Normally you would not want nicknames in PGN. PGN are intended as a medium for interchange. People might publish their games, and if they do it with names in the player tags that are only meaningful to themselves, it can only cause confusion. I consider nicknames in the PGN a very bad thing. Primarily the nicknames are intended for display in the list, since engines nowadays have often very long and cumbersome names, indicating their compilation date, CPU-features requirements, etc.

A valid reason for using nicknames in PGN would be if you somehow configured a second copy of the same engine in a non-standard way, e.g. by an elo-limiting option, and want to distinguish them. (You might possibly want to run them in the same tourny, e.g. different versions with different time odds. Normal rating programs would choke on this, as they would ignore the TC tag.)

I believe this info is important as we are dealing with an idiot. Both Winboard and engine may go crazy because the idiot may enable the -variant crazyhouse and in fact the engine does not support it. It would be a lot of trouble.

That is a problem that is not really related to this option. The option merely determines if the engine will go into the list as one that should automatically cause the GUI to switch to Crazyhouse if it is loaded. Which would not have any effect at the time you use the dialog, as you would already be in the variant. So there is nothing to switch. The real problem is that you could be in Crazyhouse, and then use the dialog to load an engine that does not support it. Which you could do whether this checkbox exists or not. The solution is simply to make the install fail (and swicth the GUI back to game-viewer mode if it was the first engine) if an engine turns out not to support it. Or, if there is currently no game loaded, automatically switch to a variant that the engine does support.

Assuming that this works fool-proof, so that you cannot install inapplicable engines, it is still convenient to be able to limit multi-variant engines to a variant other than their primary one. E.g. many engines play both normal Chess and Crazyhouse (or Chess and Chess960), and this feature is there to enable them to install them once as normal Chess engine, and a second time as Crazyhouse engine.

BTW, in my latest attempt I already had implemented mentioning the actual variant in the checkbox text (see below). And it will be disabled in 'variant normal'. (Not sure if that is good, now that I think about it.)

For optional, its for simplicity. In the Advanced (special cases only, as per engine README file), see the as per engine README file, but you have Special Winboard options: and directory and command line parameters. It is somewhat inconsistent.

Well, ideally an engine README file would also specify if any special GUI options are needed to run the engine (such as /xreuse, because it cannot play more than one game). But perhaps this is expecting too much. But you could call this "erring on the safe side". I want to make it quite clear that there is no justification for touching anything inside that box for an idiot user, unless explicitly instructed to do so.



(The list-management buttons are currently just for show; they don't do anything. There still seems to be a conceptual problem of what to do when the user opens the dialog only for reorganizing the list. If he presses OK he would load a new engine, so he should exit by pressing 'cancel'. Which is pretty illogical, as you might expect that this would also cancel the manipulations he did to the list.)

[Ferdy]

I still don't understand the usage of directory in Winboard. Perhaps in Xboard I don't know. The user can just locate the engine file thru the green button and it is done.

What if the 'engine' is Nodejs or the Python interpreter? The directory where you installed Python is not relevant for the engine.

Does that mean the user is required to fill up the directory text box when nodejs or python engine is going to be installed?

[hgm]

Indeed. Then the interpreter becomes the engine, and the engine file (.py or .js) becomes a command-line parameter. Possibly in addition to other parameters. The directory would then likely have to be where the engine file is, to make it possible for the engine to find, say, its opening book.

I agree that this is not ideal. For Java engines it is already fixed: you can browse to the .jar file in the engine field. WinBoard recogizes the .jar extension, and prefixes the engine file with "java -jar " to make the engine command. For Java you can do this, because it is typically installed in such a way that 'java' becomes a valid command that you ca give from a terminal. (So probably the Java install directory is added to the %PATH% variable.)

For Python this turned out not to be possible; even for people that have Pytho installed, 'python' does not become a valid command. And the install pathname cannot be guessed, and is in general dependent on the Python version (like C:\Program Files\Python6.4\python.exe).

I didn't check how it is with Nodejs; this is a relatively new phenomenon. but people are also writing engines in Go or Haskell nowadays, and I have no idea what else is out there.

A better soution is imaginable, but not trivial to implement. WinBoard could check if the idicated engine file has an extension other than .exe or .bat (or .jar, which can be handled automatically), and if it has, pop up a notice on pressing OK (without closing the Load Engine dialog) to inform the user that his engine is written in a non-standard programming language, which needs an interpreter to run, and that he has also has to browse to that interpreter. WinBoard could then automatically transfer the filename in the 'engine' text entry to the 'engine parameters' text entry, so that the user can now use the browse button again to point out the interpreter's .exe. And the directory part of the engine path could be transferred to the 'directory' text entry. This would still not work if the command needed to run the interpreter on the engine would require extra parameters (like the -jar in the Java example); the user would then have to add these in front of the engine filename in the 'engine parameters' field. This whole precedure would entail the risk that even expert users that know exactly what is required will not be able to do it anymore due to unexpected GUI interference, while idiot users are still not helped because they have no idea of what options the interpreter needs.

[sovaz1997]

I believe that we can really create an ultimate, pefect, cross-platform and open-source chess GUI. But it should be modular and consist of several modules, each module should have its own set of functions, but all modules should have one core. I propose to think in this direction: which modules should be in this program? It is desirable to cover everything (engine tournaments, chess engines testing, analysis, webcasting, training, working with a opening books, working with chess bases, endgames, etc...). I think the modules should not be very much (no more than 10).

My goal is to come up with a chess shell with all the details. And then go to the implementation phase. Moreover, there may be many implementations, but the main thing is that the chess gui satisfies the needs of people. Of course, it should be all good: the speed of work, and the interface, and features.

That is why the 3 stages:
1) create a model with all the details;
2) implement;
3) choose the best implementation.

This idea has appeared in my head for a very long time. But when the Arena disappeared, I remembered about it again.

P. S. Sorry for my English

[Raphexon]

It would be cutechess-cli with a GUI. So the current GUI of Cutechess but with extra options like seperate time controls for each engine.

[sovaz1997]

It would be cutechess-cli with a GUI. So the current GUI of Cutechess but with extra options like seperate time controls for each engine.

Yes, but this is already an implementation. Now we need to create a model. Personally, I will periodically write in this thread with ideas. When the concept appears, we can draw layouts. And not only I can do this, but any person. And the community will choose the best interface. The goal is to create a concept, and the implementation itself will come. Yes, it is quite possible to implement in cutechess-cli in this sense. I also plan to develop my own, but I don’t know yet how difficult it will be.

Why I said about the kernel: it can already be implemented (for example, cutechess-cli), but there is no ultimate user interface.

This is a big goal: to create the best free chess shell in the world. And I am not ready to take all the responsibility on myself, so I hope that together we will do it in the next few years.

[sovaz1997]

Cutechess-cli is an excellent basis for creating a Chess GUI testing system.
"Open Chess" - let it be the code name. Or let the community come up with a name. Just open GUI. This is exactly the model, not the implementation. All the same, that there is a standard of a programming language, and there are its implementations.

[sovaz1997]

Ok, at this stage, I see 5 modules:

+ Analysis
Analysis module Allows you to view PGN-files, view games, analyze them with engines, comment.

+ Testing
Module testing chess engine. Allows you to flexibly set test parameters (for example, SPRT testing or testing with a fixed number of games), the ability to set the testing queue, the ability to pause testing.

+ Tournament
Creating tournaments engines with different modes. Also, the generation of Web-pages for broadcast tournament on the network.

+ Playing
Game Mode. Ability to play against the chess engine or against yourself.

+ Learning (optional)
Learning mode. The ability to create interactive books on chess.

Are these modules enough? Or can some of them be combined, and some divided? Write your suggestions. When we select the modules, it will be possible to start working each separately.

[leavenfish]

To make this appeal to more than just people who run engine vs engine games (ie: the rest of the world)..you might give more thought to an ability to do various 'work' by the individual...taking some of the best ideas from some of the best GUI's.

I ran quickly thru these pages and did not see certain things, or not particularly fleshed out idea, which would likely go under 'analysis':

1. A 'pass' function. In Chessbase this is the X key. It lets you pass a half move so as to get a better idea of what the other side is threatening or what move(s) it would consider if the side to move 'passed'.
2. A nice way to store and edit your opening repertoire (think Chess Position Trainer or COW for example). I use that daily.
3. In #2 should be a way to train (test your memory for the most part) a set number of half moves starting from 'tabias' which one could manually set and therefore adjust as one gets better at recalling his repertoire. Doing that for a user set # of moves in each of the other sides possible lines as well.
4. Having the analysis engine of your choice running - and being able to freeze it at a certain move - while you are navigating would be ideal...that lets the engine chew on a position while you do other work.

Just some thoughts.