TalkChess.com

1)What is the best language to write gui?
2)What is the smallest free source code that is about gui that people can learn from it about chess gui(not that it does not have to be gui for chess and it can be gui for another game when it is possible to write gui for chess by similiar ideas)
3)replace smallest with simplest
Is the answer still the same?
Note that not always smaller is simpler so maybe the answer is negative.

Uri

Uri Blass wrote:1)What is the best language to write gui?

Personally, I think it'd be C++ with wxWidgets.

or Java.

Guetti wrote:or Java.

or TCL/TK?

Uri Blass wrote:1)What is the best language to write gui?
Uri

Probably the language where you are most familar with - but gui-programming is quite different to standard console applications, message or callback oriented...

Some alternatives:

For windows one may use:

• C and native windows (WinMain, RegisterWindowClass etc.) (arggg)
  C++ and MFC (argg)
  Borland Delphi
  Visual Basic

More portable:

• C++ and QT widgets
  Java Swing
  Java Eclipse like widgets
  TCL/TK http://en.wikipedia.org/wiki/Tcl

Gerd

I'd highly recommend Delphi. IMO it's by far the easiest and most powerful language for writing GUIs. It's OK for chess engines and may be 30% slower than highly optimized 'C' but it's still OK. That 30% penalty is irrelevant when it comes to GUIs. That's why so many high quality applications are written in Delphi (Arena, Skype and Feedemon come to mind. See also:

http://en.wikipedia.org/wiki/Borland_Delphi

You can download a free version here:

www.turboexplorer.com

Steve

Uri Blass wrote:1)What is the best language to write gui?
2)What is the smallest free source code that is about gui that people can learn from it about chess gui(not that it does not have to be gui for chess and it can be gui for another game when it is possible to write gui for chess by similiar ideas)
3)replace smallest with simplest
Is the answer still the same?
Note that not always smaller is simpler so maybe the answer is negative.

Uri

Some examples with source code that you can peruse for yourself:
SCID is written with TCL/TK and C.
Jose is written with Java
Winboard uses Windows API calls (the Xboard version uses X-Windows)

I think that the easiest way would be to use either .net languages like Vb.NET or C# or to use Java.

Java has an advantage in that it will also work on Unix and .NET languages would require MONO and still be painful if you use any custom controls.

Gerd Isenberg wrote:

Guetti wrote:or Java.

or TCL/TK?

tcl is substantially under rated. I would vote for tcl/tk for a good GUI. It's also an excellent cross-platform choice.

To Don:

Your CGOS viewer is quite nice in TCL. I was pleasantly surprised when I used it, it seemed much more nice looking and responsive than a Java app.

To Uri:

I do think Java is very easy to use though. I wrote a full integrated GUI+chess engine in Java for a high school project in a few months. If I can find the source I can send you a copy. Of course the GUI is is incredibly simple, and doesn't use any protocols or anything. I can't imagine the whole thing was more than 1000 lines...

My old interface was in Delphi, which was pretty good.

Currently, I'm rewriting it in C#, which seems to be even better.

I specially like the usercontrols, ie a more "on the fly" form of Delphi components.

What is more important, is to design the message flow.

I have all the controls (boardControl, gameNotation,EngineOutputParser) raise events (but not respond) on the input, wich are all caught by the mainform, who reacts by sending messages to the controls to respond to (update board, gameNotation etc)

So if you click on the board, the board raises an event (move"e2e4"clicked), the mainform checks if the move is OK, and sends to the board: Move"e2e4";update board, and to the gameNotation: Move"e2e4";update notation.

It's very easy to mess up if you're not experienced with the language. Especially if you have to wait (ie block the thread) for a certain event.

It happend quite a few times I was waiting for an event, wich I accidently blocked as well.
The point is that some things have to happen synchrone and some asynchrone. This doesn't combine nicely with a multithreaded interface.

The visual part is easier, if you happen to like making that kind of stuff.

Tony