Elements of the ULTIMATE Chess GUI?

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

[sovaz1997]

Thank you very much for the ideas!
Regarding the 4th point: I plan to do this seriously. For example, you have problems with electricity. Or you need to leave. Or you need PC resources for another application.
The smoothness of the UI is a very important thing and it's good that you noticed it.

There will be Task Manager, created specifically for the GUI. You can close the program, and after opening it will restore the analysis and all running processes. You can pause the analysis / testing, etc. The analysis process can be saved either completely (with the process status, hash), or partially (saving the PV and after the engine hash table is correctly filled with many quick launches).

Now I am developing an interface design. This is a big job and I have a lot of ideas that will have to go through a public test

-------

The idea on the engines: first, auto-update. For open source this download and automatic compilation. Then - for each engine - its version history. Also, for each version - the ability to store different settings of the engine. This idea can be further developed, but now it is not the main thing.

Next - the ability to view the game in real time with all output (this is for the game engines). I think this is a more specialized thing.

Also, the best work with PGN. You can simply bring the move to the PGN (and this can be a PV engine, or a move from the analysis of the game) and open it in a separate window for analysis.

Resource management: you can have many positions to analyze. In this case, you can do the testing engine, as well as do some kind of tournament with the broadcast to the Internet. Task manager himself will say that you can run, and that - you can not. You yourself allocate available resources.

Regarding testing engines: here you can make it possible to test on different PCs, but combine one result.

[sovaz1997]

Now further: at first I thought about 5 modules. Now I am thinking about 4 types of tasks (I don’t include training yet, this is a further development of interactivity). Analysis, Tournament, Testing and Game Mode. Tasks are divided into 2 types: interactive and background. And here we have great opportunities: it will be possible to plan background tasks. Tasks will be executed in parallel if resources allow. Interactive tasks will drown out background tasks. A task can be anything from 4 types. The background may be 3 tasks - analysis, tournament and testing. A convenient taxi manager will allow you to manage tasks and plan them. Task Modes: running, ending, waiting, paused. It will be possible to swap them, change the mode of the task: switch from background to interactive mode for analysis, for example. It is always possible to limit shared resources in the background and in interactive mode. Also, when the task is completed, all actions are saved and it is not deleted anywhere.

What do you think of it? I think there is a lot of room for improvement

[hgm]

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.

I am of course still following this thread with interest, as ideas that are good for an ultimate GUI we might have in 10 years or so, of course could be good for WinBoard as well tomorrow.

1) WinBoard already has, but it is a bit tricky: you cannot offer engines a pass as input, so you would have to restart them from the position after the pass. This sometimes leads to problems with engines that do not properly implement setting up of positions from a FEN.
2) Is this in any way differetn from the WinBoard 'Edit Book' function, where you get to see the list of book moves and their weights for the currently displayed position in an editable window?
4) Not sure what you mean by 'freeze' here. I would think 'freezing' is the opposite of 'chewing on a position'. Engines always keep analyzing the current position as long as you do not take action to change it (by moving or retracting a move) during interactive analysis, do they not?

Note that the idea to be able to 'hybernate' an engine during power down, to later restart it with the hash preserved, is very nice, but not something a GUI can do. Only the engine process has access to its own memory (which contains the hash table). So the possibility to pause execution and / or save hash must be implemented in the engine to be possible at all. (Unless the operating system would offer general possibilities to mothball processes that way, which I don't think any popular OS does.)