Object model for chess GUI?

[Steve Maughan]

(...)I agree with Lucas here. Delphi is last century technology (but perhaps is what the author knows)

Hi Marco, Lucas & Bajusz,

Delphi is certainly not trendy but it's far from dead. There are compilers for Windows 32 / 64, OSx, iOS and Android (and Linux soon).

I'd say Embarcadero resuscitated the old dog and it's alive and well. Take a look at the TIOBE ranking - it's #13 up 3 places from last year:

http://www.tiobe.com/index.php/content/ ... index.html

As others have pointed out, it's also a question of what I'm aiming to do. I'm really familiar with Delphi so it's my first choice. Although I'm also interested in learning Python so I may dabble there and see how difficult it would be create a GUI.

Thanks,

Steve

[stevenaaus]

In XBoard the games is stored as an array of positions.

No Way! No wonder it is such a ... beast. It'd make handling variations alot easier.

Steve - I'd start by cutting up Scidb, which has a great OO foundation, but C++ of course. Rewrite the GUI in it. But you are crazy of course. Just give Gregor a hand with Scidb instead. Two people making a OO chess GUI will almost get there in 5/10 years.

Dann - what did you code in wxWidgets ?

[Dann Corbit]

In XBoard the games is stored as an array of positions.

No Way! No wonder it is such a ... beast. It'd make handling variations alot easier.

Steve - I'd start by cutting up Scidb, which has a great OO foundation, but C++ of course. Rewrite the GUI in it. But you are crazy of course. Just give Gregor a hand with Scidb instead. Two people making a OO chess GUI will almost get there in 5/10 years.

Dann - what did you code in wxWidgets ?

Just toy apps. I wanted to become proficient, but found it frustrating.
I have done a lot of dotnet programming, but I do know it isn't really as portable as promised. I have done a little Java too, but that language is so big it gives me a headache:
c << C++ << Java
C is small enough that the grammar can fit on a couple pages (with C89 at least).
C++ needs a few hundred pages.
Java needs the Library of Congress.

I have done a teeny bit of Tcl/Tk (really just did some modifications of SCID so that it will hold 16M games).

The bulk of my graphics work is from way back in the day (CGI and PHIGS APIs to do presentation graphics and GIS programming). I wrote a product called G-Wiz graphics in the 1980's and also a GIS package called the NSB Oceanographic Information System.

That kind of graphics is low level and tedious. I also worked on a Font System (ASI Font System) and an HP/GL translator.

I would like to find something portable, simple, and functional. But all of the approaches are necessarily complex.

I like graphics and I would like to try my hand again at presentation graphics, GIS work, and even a Chess interface to a SQL database. But I don't really have enough time for that now.

[stevenaaus]

Yes, from recollection, wx is pretty low level. But i liked what i've seen.. and it seems quite underused. Java is big too, is it. Well - another reason to stay away from it
I quite love tcls smooth functional programming style. I mean - everything is a string - more or less.

S.A. wrote
- It'd make handling variations alot easier.
+ It'd make handling variants alot easier.

[hgm]

- It'd make handling variations alot easier.
+ It'd make handling variants alot easier.

I understand that even less. Why would it matter more for variants than for orthodox Chess? You have to be able to derive a position from a sequence of moves anyway (when loading PGN, or from moves played by the engines), so I don't see many problems with a representation that only stores moves. Storing all positions just seems a design choice.

[ilari]

My experience with CuteChess:

* For us it was definitely the right idea to separate the front-end (GUI) and back-end (the library). This makes it easy to provide a command line tool that doesn't have any window manager dependencies and helps to keep the codebase clean and modular.
* Be prepared to rewrite a lot of stuff as your GUI gains more functionality
* Use good abstractions. For example CuteChess has a ChessPlayer class, and HumanPlayer and ChessEngine classes that inherit it. And UciEngine and XboardEngine classes that inherit ChessEngine.
* As others have said - if there's a good library or framework, use it. Some people say that Qt is bloated, but depending on what parts of it you need, your installation package doesn't have to be 100MB. The VLC media player (which uses Qt) for example has a 28MB package for Windows which is very reasonable these days.
* Don't worry about performance too much. This is why it's usually more fun to develop a GUI than an engine.

If I had to start writing a GUI now, I'd probably do something along the lines of what Marco suggested - make the GUI run in a web browser. I'd still need to develop a native server application that would enable communication between the engines and the GUI. But that would be a fun thing to do.

[hgm]

In Win/XBoard the front-end is very well separated from the back-end, because WinBoard and XBoard have completely different front-ends, and we now even have alternative front-ends for XBoard (Xaw or GTK based). Apart from the window-manager-related stuff, there is also the non-graphical interaction with the OS, that is either through *NIX-like system calls or through Windows API.

The annoying thing that does make it non-trivial to turn it into a command-line tool is that for event dispatching in all cases it still depends on the widget set's event loop, and that the command-line tool would still need the input and timer events. It is still on my to-do list to create an alternative for this (e.g. based on threads that do blocking input, and low-level timer functions).

[Steve Maughan]

My experience with CuteChess:

* For us it was definitely the right idea to separate the front-end (GUI) and back-end (the library). This makes it easy to provide a command line tool that doesn't have any window manager dependencies and helps to keep the codebase clean and modular.
* Be prepared to rewrite a lot of stuff as your GUI gains more functionality
* Use good abstractions. For example CuteChess has a ChessPlayer class, and HumanPlayer and ChessEngine classes that inherit it. And UciEngine and XboardEngine classes that inherit ChessEngine.
* As others have said - if there's a good library or framework, use it. Some people say that Qt is bloated, but depending on what parts of it you need, your installation package doesn't have to be 100MB. The VLC media player (which uses Qt) for example has a 28MB package for Windows which is very reasonable these days.
* Don't worry about performance too much. This is why it's usually more fun to develop a GUI than an engine.

If I had to start writing a GUI now, I'd probably do something along the lines of what Marco suggested - make the GUI run in a web browser. I'd still need to develop a native server application that would enable communication between the engines and the GUI. But that would be a fun thing to do.

Ilari,

Many thanks - certainly helpful.

The ideal of using the web browser as the GUI is interesting. I guess I could use Python for this.

Cheers - Steve

[Henk]

Perhaps start with dragging a piece. I still have problems with that for I use HTML5 dragging and I better use JavaScript. But that's about websites.

Mouse event handling might not be easy.

I will be interested if you post your solution for dragging a (chess) piece in the browser. By the way I use ASP.NET MVC

[hgm]

I recently created a universal JavaScript code for displaying 'interactive Chess diagrams', which basically are simple GUIs (allowing piece manipulation and indicating legal moves). For the dragging I just used the browser's default action. This has the problem that the piece does not disappear from its origin square when you start dragging it. As I could live with that considering the intended application, I did not make any attempts to cure that (which I am sure would be possible).