JonasThiem wrote:Does Komodo have a GUI? So far I'm only planning to write something for GUI developers as a help... although now that people keep asking for it, I guess creating a library for the engine side might also be a good idea at some point.
No, Komodo does not have a GUI yet.
But I do want Komodo to support both protocols, I just have been lazy getting to that.
Don
Capital punishment would be more effective as a preventive measure if it were administered prior to the crime.
It seems to me that it is also more difficult to cast the engine side of the interface in the form of a library, as the server-client relation is inverted there. So it is not so much a number of services you need there, to call upon, but a main loop which calls the engine servics like Search, MakeMove...
hgm wrote:It seems to me that it is also more difficult to cast the engine side of the interface in the form of a library, as the server-client relation is inverted there. So it is not so much a number of services you need there, to call upon, but a main loop which calls the engine servics like Search, MakeMove...
Yes, there may be too much "plumbing" to make this very practical.
Don
Capital punishment would be more effective as a preventive measure if it were administered prior to the crime.
I just want to point out that the project is 100% useless unless you change the license.
JonasThiem wrote:Hello fellas,
I'm planning to write a C/C++ engine handling library and would like to hear some comments on its usefulness and the interface.
Why?
I noticed many GUIs support either UCI or Winboard rather incompletely, or even just one of the two. Also, rewriting the code to set up another process with pipes for each new GUI seems to be a bit tedious (as most would probably do it the same way, the major differences lie somewhere else I suppose).
How?
So I thought I would write a library: libchessinterface. It would incorporate close to zero chess knowledge, so all the chess knowledge and support for variants etc etc would be up to the GUI. The library wouldn't be limiting you here, but also not assisting.
All the library would do is launch the process for you and provide a uniform interface that hides the differences between UCI and Winboard/CECP. Since UCI is a bit simpler due to bein stateless, the interface probably looks a bit more like Winboard than UCI.
Would you mind to explain? Many libraries use LGPL licensing (e.g. SDL 1.2, non-commercial Qt gui toolkit, older Ogre3d versions, ...), and they're happily being used in closed-source or commercial programs.
I've studied your sources. It's an interesting project, but it's a little ambitious for your first attempt. Do you think so? I encourage with your development but support much less functionality at least you have a stable version that can play and analyze some games. For example, you don't need to implement chessinterface_Usertalk, this is a very engine specific functionality.
I've already attempted what you want to do. My interface is much more simpler than yours, it supports UCI, WB and FICS protocols brilliantly. I can use this interface to play timed games and analyze games. The implementation spawns a process for the engine.
If you keep your goal less ambitious, maybe you can convince a new GUI developer.
class VirtualProtocol
{
public:
virtual ~VirtualProtocol() {}
// Open connection to the protocol
virtual void open() = 0;
// Commence from a default state
virtual void start() = 0;
// Request a move from the other player
virtual void request(unsigned int duration) = 0;
// Analyse the current state for specified seconds
virtual void analyse() = 0;
// Stop the current operation
virtual void stop() = 0;
// Return true if the other player is ready
virtual bool isReady() = 0;
// Close the protocol and its underlying connection.
virtual void close() = 0;
// Update the board to state
virtual void update(const std::string& state) = 0;
// Update the board by a movement
virtual void update(int srcFile, int srcRank, int dstFile, int dstRank, const VirtualPiece& promote) = 0;
};
I've studied your sources. It's an interesting project, but it's a little ambitious for your first attempt. Do you think so? I encourage with your development but support much less functionality at least you have a stable version that can play and analyze some games. For example, you don't need to implement chessinterface_Usertalk, this is a very engine specific functionality.
I've already attempted what you want to do. My interface is much more simpler than yours, it supports UCI, WB, FICS and ICC protocols. I can use this interface to play timed games and analyze games. The implementation spawns a process for the engine or connect to the Internet if FICS or ICC.
You won't convince any of the existing GUI switching to your library. But your attempt will be noticed by someone who just wants to do a new and simple GUI and want to quickly connect to an engine, for example, a university project or a weekend project. They will use your code if you keep it dead simple.
class VirtualProtocol
{
public:
virtual ~VirtualProtocol() {}
// Open connection to the protocol
virtual void open() = 0;
// Commence from a default state
virtual void start() = 0;
// Request a move from the other player
virtual void request(unsigned int duration) = 0;
// Analyse the current state
virtual void analyse() = 0;
// Stop the current operation
virtual void stop() = 0;
// Return true if the other player is ready
virtual bool isReady() = 0;
// Close the protocol and its underlying connection.
virtual void close() = 0;
// Update the board to state
virtual void update(const std::string& state) = 0;
// Update the board by a movement
virtual void update(int srcFile, int srcRank, int dstFile, int dstRank, const VirtualPiece& promote) = 0;
};
