Skip to content


April 29, 2012

Clearly I am in one of my periodic (or is that persistent?) phases of low Tarrasch activity. I’ve probably explained this before, but if so it’s worth repeating: I am actually now comfortable with (very) slow progress. Before I delivered Tarrasch V2, I was never comfortable. I wasn’t comfortable because I felt that I hadn’t yet produced something really useful. Tarrasch V1 certainly never cut it, in my mind anyway. But now I can point at Tarrasch V2. It sits on my PC and I use it every day, for a range of simple chess activities. For those activities at least, I much prefer to use Tarrasch than the alternatives that I am familiar with. There are other people who feel the same way. So to some extent at least I am happy to sit on my laurels.

However. This doesn’t mean I don’t want to improve Tarrasch. It has plenty of weak spots and in many ways is really just one big “opportunity to improve”. So, where to start ? For now I will simply present a roadmap. This is a plan for future development. I am not going to commit to do any of this stuff in any kind of fixed time frame. But assuming I don’t lose interest in chess computing I do intend to get there eventually. There are some tiny things and some huge things. Enough introduction, let’s put some meat on the bones.


  • Optimization to allow editing of much larger .pgn files
  • Use canonical std::vector deletion algorithm to speed up mass deletes on game dialog
  • Fix reported screen irregularity from a user on his unusual Dell setup
  • When kibitzing, if engine sends “bestmove”, show it, because the engine isn’t going to send anything more
  • In .pgn editing we only support comment text before a move for moves at the start of a variation, but we also need to support comment text before moves that come immediately after a nested variation, for example we need to be able to edit Text4a in the following;
    Text1a Move1 Text1b Move2 Text2b ( Text3a Move3 Text3b) Text4a Move4 Text4b
  • If pgn tags (players, date etc.) are pasted into the moves window they should be recognised and interpreted
  • Restore missing pixels on the right edge of the h file
  • Fix> Delete key no longer works on game dialog for some reason
  • Fix> Editing of game variations and comments slows down dramatically as game gets very large

New Features (small)

  • Click on piece to move for move menu, or instant move if only one move possible
  • Keep a list of recently accessed files available in the file menu
  • Generate ECO codes for new games
  • Allow user to hide the lines and just show the evaluation (number) in human v computer games
  • Chess 960 support
  • More UCI user parameters
  • More menu separators
  • Analyse/blundercheck file/game
  • File > Save Game As feature
  • All Save/Save as features ask “Do you want to replace or append ?” if the selected file already exists

New Features (large)

  • Animation, move arrows, play-stop (the humblest javascript web player seems to have these now – Tarrasch should too)
  • Revamped display system (customisable fonts, resizable graphics, more flexible layout and panel sizes, optional co-ordinates)
  • A proper engine management system, including persistent parameter discovery and editing (using the gui)

Package Enhancements

  • Ask for permission to incorporate Critter, Stockfish, Houdini

Development Changes

  • Break out the “chess API” into a static library, with improved naming, a test suite, chess960 support
  • No compiler warnings
  • More portable implementation of move tree
  • No use of Windows thread pause which is intended for debuggers only
  • Change from bitbucket to github
  • Split off a development branch, allow users to download “under development” intermediate versions

Possibilities for the Future

  • Publishing features
  • Mac version
  • Engine v Engine

Some of these points require further elaboration. I might edit that in later, or I could add follow up posts. In the meantime, if I promised you something that doesn’t show up in the roadmap above, please remind me in the comments and I’ll update it!


30 Comments leave one →
  1. April 29, 2012 8:38 pm

    no promises made to me 😉 but one suggestion in addition to permissions to package with other engines would be to add Hermann 2.8 … it is a free engine (of course) and i have been messing with it for about three months (note: not a full-fledged analysis as the experts on the computer chess community would do … i am just a woodpusher who loves freeware gui’s and engines) and i have found it to be a very very good engine … more positional, strategic and conservative probably than say Houdini but i find it to be a great engine to play against and to use for postgame analysis … just a suggestion 🙂

    here’s a link thru the Arena page that has a bit more general info and is in english (it is a German engine):

    also glad to see optional coordinates on the list 🙂 it just helps with recognition that much more 🙂

    thanks again for the fine program 🙂

    • June 3, 2012 2:17 am

      Sorry for my very slow reply. I played with Hermann once when I was first starting out on the project and looking at Arena. It seemed a nice enough engine, but of course there are (litereally) hundreds of engines! That’s one of the reasons I decided to do a GUI rather than another engine.

    • June 3, 2012 2:19 am

      Thanks James. I’ve heard from you a few times on this topic. Maybe now that Tarrasch is open source you can adapt it yourself. Not a priority for me.

  2. May 27, 2012 3:41 pm

    Just a couple of smaller additions to your nice GUI

    Adding of multiple chess engine kibitzers running
    Ability to set the number of lines in kibitzing mode

    Else a very nice and easy to use chess workbench

    • June 3, 2012 2:19 am

      Thanks, both of your suggestions are sensible and may make it in some day.

  3. Boris permalink
    June 2, 2012 10:36 pm

    Another feature request: adding a keyboard shortcut for engine “Commands -> Move Now”.
    And why is there no native Linux/Mac/BSD version? WxWidgets is cross-platform and specifically designed to run on different platforms. If you are not planning to port it to other platforms then why did you use it in the first place? Using Win32 Api would seem far more reasonable choice.
    All you would have to do is write few make files and correct some api calls!

    • June 3, 2012 2:34 am

      > If you are not planning to port it to other platforms then why did you use it in the first place? Using Win32 Api would seem far more reasonable choice
      This is not true at all actually. The wxWidgets API is far more consistent, well organised, and usable than the raw Win32 Api. I’ve wasted vast tracts of time on MFC (thin wrapper around Win32) programming, for example see my Reptor program. Taking the time to start again using wxWidgets instead of MFC/Win32 was one of the best decisions I made when abandoning Reptor and starting Tarrasch. The way I see it, the portability advantages of wxWidgets are just a bonus. Unfortunately, even using wxWidgets extensively doesn’t mean porting Tarrasch is a trivial exercise. I’ve used some native windows APIs in a few places for example. So, the bottom line is that although I *planned* to port to other platforms, I haven’t yet got around to it.

      • June 3, 2012 12:23 pm

        Trying to compile Tarrasch on Windows made me realize how much I hate it.
        I spend 2 hours trying to install Visual Studio 2010 only to find that it is incompatible with WxWidgets 2.8. Now I will try to compile Tarrasch with 2.9. My goal is to first try to compile it on Visual Studio, then Visual Studio pedantic mode (it may be called something different on VS), then MinGW and then eventually to port it to other platforms.
        Update (30 minutes later): The only incompatibility I found so far was the use of the timer. I believe wxTimer can be used instead (I will look into it later). There is also a lot of little things like
        class t { public: t::t() {}}; instead of class t { public: t() {}};
        And sorry for my bad English.

  4. June 8, 2012 7:45 am

    Hello Bill.

    Thanks for your software.

    I like the usability of Tarrasch related to the minimalist approach: eventually I can focus on analyzing and commenting the games and I am not distracted by bells and whistles.

    “No install version” and “inserting automagically a comment” are my preferred features.

    A few suggestions after testing my chess workflow.

    – Paste a pgn with tags (it is in your roadmap).
    – Add the missing pixel (it is in your roadmap).
    – Fix MultiPV option in engine dialog (as workaround to set the number of lines in kibitzing mode – see Kim’s comment): when I browse the game, that option is ignored, kibitzing again 4 lines.

    New Features
    – Set a (very) nice icon (it is important to give a brand to Tarrasch). 🙂
    – Remember the last game loaded and the last file loaded (it is in your roadmap as to keep a list of recently accessed files available in the file menu).
    – Add a shortcut to open the game list of the current file loaded (and one for the log).
    – Add a feature to remove all comments.
    – Add a feature to remove all variations.

    Development changes
    – I vote for “Change from bitbucket to github” (I am sure I would contribute and the collaboration, in terms of pull requests, issues track and code review, is well supported).

    Add in FAQ
    – Why the backspace key doesn’t delete a move? Because it is used to delete the text in a comment and there is not danger to wipe out a few moves unintentionally, keeping pressed the backspace key. 🙂

    Thanks again for your so useful software.

    P.S.: the use of “desiderata” was not intentional: it is a minus in language proficiency. 🙂

    • June 9, 2012 12:13 am

      Thanks Alberto. Alberto originally contacted me with this useful contribution by email, and I asked him to post it here as well to make it more visible and harder to forget about. I see Alberto has put some extra work in and this post is even better than his original email. One slight quibble I have is that I think proper support for MultiPV is a “New Feature” rather than a “Fix”. There is a “Max CPU cores” engine option, which works with Rybka at least (other engines I’ve looked at don’t have an equivalent option). Incidentally, Alberto originally used the beautiful but very obscure (in English) word desiderata to describe the new features he wants. By email I complimented him on using such a nice word, on reflection I suppose that it is a common word in Italian that we English speakers have shamelessly stolen and then neglected.

  5. Vitaly Ivanov permalink
    August 3, 2012 9:04 am

    If you’re really planning to develop Mac version as well, I strongly recommend using Qt — it’s truly cross-platform (Windows, Mac, all sorts of Linux, no iOS support so far unfortunately), free for open source projects, well documented, etc. I don’t think there’s anything else as convenient for cross-platform GUI development as Qt. As far as I remember, there are also a few samples in Qt SDK itself which are supposed to illustrate drag-n-drop handling, but can be easily adapted for position set-up.

    • Kostya permalink
      August 3, 2012 9:19 pm

      Why would he use Qt, if Tarrasch is already written in WxWidgets? WxWidgets is also cross-platform and works great. Plus, if I remember correctly, Qt forces programmers to use their own build program for signals, etc.
      Since Tarrasch is mainly a GUI, switching to Qt would mean re-writing 90% of the program, as opposed to, for example, an engine itself, where the re-writing of the code would be much much less.
      Did you ever use WxWidgets, yourself?

      • Vitaly Ivanov permalink
        August 4, 2012 5:16 am

        Ah ok, I didn’t know that — thought that it’s MFC or something. I neither looked into Tarrash code nor used WxWidgets. So what’s the problem with Mac version if WxWidgets is so great and perfectly cross-platform?

      • August 5, 2012 5:27 am

        Well, actually I think WxWidgets might have been a mistake and Qt might have been a better choice. WxWidgets is certainly a big improvement over MFC (my previous Windows GUI programs have been MFC) but I have a bad feeling it is a dying platform. For example, on Mac WxWidgets *still* uses Carbon. Apple moved to Cocoa and marked Carbon as end of life years and years ago. This was a big disappointment to me when I bought a Mac and started playing around with the dev environment, thinking about Tarrasch for Mac. There are other barriers to getting a Mac version going though. I cheated and used some Windows specific graphics code even though I could probably have managed with pure wxWidgets. And all my UCI engine code is Windows specific. It’s a mess, I hate it, I need to re-write it, but it works and runs the engines pretty well. In fact plenty of people have told me they get faster smoother operation of UCI engines from Tarrasch than other GUIs, and if that’s really true it’s probably because I used Windows APIs for process control rather than portable Unix/Posix style APIs.

        I was thinking about a Mac Tarrasch again just the other day, and the scheme I came up with then was to do a big tidy up ensuring all GUI code was strictly quarantined into a nicely designed GUI subsystem, then to write a native Cocoa version of that subsystem. This seems to be the approach recommended by many wise heads for porting apps to Mac.

        The truth of the matter though is that whatever scheme I finally use, the real barrier is finding the time and motivation to get the job done.

      • August 5, 2012 5:27 am

        Thanks Kostya, but see my reply to Vitaly.

      • Kostya permalink
        August 5, 2012 12:20 pm

        @Vitaly Ivanov
        I didn’t know that WxWidgets didn’t work properly on Mac, since I don’t own a Mac, never used a Mac, and will probably not use it in the near future.

        Qt is a great API, and I use it myself, but since the Tarrasch is already written using WxWidgets, I thought it would be much easier to port it to other platforms, especially for triplehappy, since he already knows and uses it.

        Actually, my only experience with wxWidgets was wxHaskell. In C++ GUI programming I usually use Qt, which has really nice documentation.

        “I cheated and used some Windows specific graphics code even though I could probably have managed with pure wxWidgets.”
        @triplehappy Yes, I browsed the source code, and tried to get it to compile on Linux, but I ran into a few problems when compiler errors pointed me to BMP code where you converted WxWidget bitmap into Windows version, to get width, height, and width bytes. There was a native WxWidgets function to get width and height, but I was not sure what width bytes was, and only Windows class had it.

        “Because I used Windows APIs for process control rather than portable Unix/Posix style APIs.”

        I don’t know much about programming on Windows, but from what I understand Posix/Unix subsystem on Windows is limited and should not be used for real programs.
        One could use cygwin, but that would indeed be slower, and it’s a horrible idea for native Windows program, unless you are porting from *nix (it’s like writing programs for Linux, and using Windows API, and running program in Wine).
        So can you explain to me how to get Unix/Posix style APIs on Windows? It would improve my programming experience on Windows tremendously 🙂

        “I came up with then was to do a big tidy up ensuring all GUI code was strictly quarantined into a nicely designed GUI subsystem, then to write a native Cocoa version of that subsystem”
        Great idea. If you do this, it would be much easier to port Tarrasch to other *nixes, using any library like Qt, GTK+ or even XLib xD.

  6. Bill permalink
    October 23, 2012 4:05 pm

    I’ve spent the last hour or so trying to get the code to build with this ____ wxwidgets thing with no luck. Would it be possible for you to zip/tar your wxwidgets binaries that work with your VS2010 solution and make it available for download? I think that would save people a lot of time. Thanks and thanks for making this open source!

    • October 23, 2012 9:11 pm

      I don’t have a problem in principle. I’ve been meaning to check what other wxWidgets based open-source projects do, because wxWidgets is so huge and has so many options etc. it can be a bit of a PITA. Especially if you want a static build (one .exe) as I do. In the meantime I will try to help you out by doing as you ask one-to-one by email. But not right now as I’ve just arrived at work. Maybe in about 12 hours time. If you can’t wait that long, even if you can wait that long, I would recommend reading carefully everything I’ve written about this – especially the idea of starting by building a simple wxWidgets demo or sample (thus taking Tarrasch out of the equation), then replacing the business logic with Tarrasch. Do a rich text edit sample if they have one – because I remember when I started using the wxWidgets rich text editor I had link problems initially.

      • Bill permalink
        October 24, 2012 12:54 pm

        Thanks. I don;t know if you have looked at the latest version, but it appears to be quite a bit different in how it is used than earlier versions. At least it looks that way to me based on project settings. What I tried to use was the binaries that they supply for VS 2010.

      • October 24, 2012 9:43 pm

        No, I haven’t really monitored wxWidgets progress – last time I looked it was pretty slow moving. If you’d like me to email you the resources you are interested in (compiled wxWidgets libraries, include files) please email me to that effect and I will endeavour to reply in a timely fashion – although I am very busy at the moment and have limited computing time at home.

  7. kansashandle permalink
    November 10, 2012 4:08 pm

    Just wanted to leave you a note. I just discovered your program. I like how it is lightweight. I use it for one-off analyses, so I am requesting no new features!

    Well, okay. Here is one. 🙂 On the setup board widget, maybe make it more keyboard friendly. You could navigate the squares with the arrows and use letters to place pieces there.

    But really, we don’t need another Arena or SCID, so kudos to you for making a great lightweight program! I am glad you are hesitant to add bloat.

  8. someone permalink
    November 22, 2012 11:27 am

    hi , Tarrasch GUI is so wonderfull and powerful “simple ” program to analyse chess , but for the Future Feature , the most realistic feature is BOARD COLOR , man… white board made my eyes tired quickly , anyway it’s wonderful program.. congratulation for this great program .. i even leaved Fritz because of this program.. 😀

    • December 17, 2012 3:22 am

      Hey someone – I had the same issue — why is the entire board white? Then I played around with my monitor’s settings and discovered that I had my contrast cranked to max. When I reduced the contrast – presto!!! – the board’s gray and white squares are there — it’s not an all-white board.

      Maybe triplehappy will add a fix for this and the board-color issue in a later update.

      Until then, I’m very happy with the Tarrasch GUI – thanks triplehappy! 🙂

      • someone permalink
        January 4, 2013 6:10 am

        hey Sir .you r right , i followed your suggestion (reducing contrast level) , then it’s not totally white, thanks…, but i still hope that Tarrasch GUI put at least one type of color on it’s board ..

  9. Kostya permalink
    November 23, 2012 2:41 pm

    What are the license of Tarrasch? I am making some changes to the code, and I will probably re-distribute it. If you do not specify the license, there can be a lot of conflicts and problems later on.

    I am planning to re-distribute the program under GPLv2. If you pick GPL or another permissive license like BSD, than there will be no problems, but if Tarrasch is not “truly open-source” than there is no point for me to work on it.

    • November 24, 2012 8:49 am

      I think the license is very clear. Each source file has a pointer to it at the top. Basically the terms of the licensing are that you can do whatever you want with the source code, as long as you don’t try to stop me doing whatever I want with the source code. So for all normal, friendly purposes, commercial and non-commercial, you are fine.

      • Kostya permalink
        November 24, 2012 5:06 pm

        “Basically the terms of the licensing are that you can do whatever you want with the source code, as long as you don’t try to stop me doing whatever I want with the source code.”

        So, for example, if I release my code under GPL, can you potentially take the source code and re-release it under a proprietary licens?

      • November 24, 2012 11:55 pm

        Ironically, you are worrying about the same thing that I was worrying about when I wrote my license; You don’t want someone else to stop you continuing your own work. It’s also ironic that I chose the most liberal possible licensing terms, basically “Do whatever you want”, and yet I get complaints about my licensing.

        I will offer the following;
        1) I won’t steal your work, you have my word.
        2) Next time I update the code I will use a well known license – the most liberal I can find – certainly not the GPL or any variation of it as it is too restrictive. Probably the MIT license.

      • Kostya permalink
        November 25, 2012 12:41 am

        “It’s also ironic that I chose the most liberal possible licensing terms, basically “Do whatever you want”, and yet I get complaints about my licensing.”

        I was not complaining; just asking questions.

        “1) I won’t steal your work, you have my word.”

        This is good enough for me. 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: