Elements of the ULTIMATE Chess GUI?

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

[sovaz1997]

Yes, I looked, we really can not save the state of the process easily. Therefore, we can extend the standards of UCI and Winboard. We introduce 2 commands to save the transposition table and restore. Teams should simply save the table, which they themselves will be able to restore on command.

[hgm]

Well, the protocols already support ways to do this: engines can define 'Save Hash' and 'Load Hash' button options (and possibly a 'Hash File' string option to specify where the hash table should be saved), and the user can then simply operate those from the Engine Settings dialog. It is not something that would need special support from the GUI; the latter doesn't even have to be aware anything like this is possible.

Note that WB protocol includes 'pause' / 'resume' commands, which are more limited (they do not cause any saving on disk), but just freeze all engine activity. (So you can use your computer for something else without losing the engine state.) Hardly any engine supports those commands, though.

Extending a protocol is easy, but it is usually also completely futile, as no engine developer will bother to implement the extension. GUI functions that depend on such a protcol extension will thus remain completely unusable / useless. So my advice is not to focus on GUI features that would only work because of newly proposed engine functionality, no matter how fantastic it would be, as in the end it will almost never work. Trying to enhance standards is a completely different and much more frustrating job than developing a GUI.

Also note that operating systems sometimes already support some of the things you propose, and that it is not clear to me that it would have any advantage at all to duplicate that functionality in a GUI. E.g. Windows does have a task manager, which you can use to manipulate the priority of an engine process (e.g. lower it when you want to do something else, to not interrupt an ongoing long analysis), or assign it to a specific core by specifying an affinity. (I often use that to assign all analyses I have running in parallel to a single core, making the others available for more pressing business). distributing the work over several computers is usually also possible without any specific GUI support, just making use of the general OS feature that allows access to files on other machines. E.g. If you want to run a tournament distributed over several computers with WinBoard, you can simply start a WinBoard instance on each computer, and instruct it to run the tournament from the corresponding tourney file in the distributed file system. This then works exactly the same as when you had several WinBoard instances running the tournament concurrently on the same machine; there is no need for WinBoard to know it was running on a distributed system at all.

[gbtami]

Yes, I looked, we really can not save the state of the process easily. Therefore, we can extend the standards of UCI and Winboard. We introduce 2 commands to save the transposition table and restore. Teams should simply save the table, which they themselves will be able to restore on command.

Andscacs has it already:

Andscacs 0.94 by Daniel Jose
uci
id name Andscacs 0.94
id author Daniel Jose
option name Ponder type check default false
option name Hash type spin default 128 min 1 max 65536
option name Clear Hash type button
option name NullMove type check default true
option name MultiPV type spin default 1 min 1 max 100
option name Threads type spin default 1 min 1 max 512
option name AlwaysFullPv type check default false
option name Contempt type spin default 0 min -100 max 100
option name NeverClearHash type check default false
option name HashFile type string default hash.hsh
option name SaveHashtoFile type button
option name LoadHashfromFile type button
uciok

[hgm]

Note that saving and restoring the hash in itself is not sufficient for restoring the complete engine state; it would still be like you aborted and then restarted the analysis.

But the main point is really that this isn't a GUI feature and doesn't require special GUI support. Controlling it through the engine options seems as good as any other method, and that is how it already works.

[sovaz1997]

Note that saving and restoring the hash in itself is not sufficient for restoring the complete engine state; it would still be like you aborted and then restarted the analysis.

But the main point is really that this isn't a GUI feature and doesn't require special GUI support. Controlling it through the engine options seems as good as any other method, and that is how it already works.

I agree. If the OS does not give the opportunity to freeze the process and maintain its state, then this should be provided to the engine itself.
Therefore, my idea with background tasks will not work as I would like. At the same time, if this option will be included in the standard, it will be very good. But at the moment it is only needed for debugging the engine, as I understand it.

[sovaz1997]

Well, I started to make GUI design. I am not a designer. Criticism is needed. This is only the first attempt (and then unfinished). I will improve the design according to criticism. Also, I will be glad if the designers suggest which literature is better to read on the subject of design.



P. S. It seems to me too many shadows. But perhaps there are some architectural problems. Also, ideas on program features are welcome.

[hgm]

There doesn't seem to be much interest...

I guess the point is that it doesn't really seem to do anything other GUIs don't do already. It just presents it in a slightly different way on the screen. Which some people will like, but most others won't, as this is purely a matter of taste, an many tastes are possible, each having their own favorites.