On retracting moves …

Wee, I can redo a move! Shiny new features entered the world of Kigo (formerly known as KGo) in the last two weeks. Let’s have a start with the full undo/redo implementation. This does not sound very noteworthy off course, but (at least the redo part) turned out to be more of an issue than I originally expected. The scapegoat is once again the wonderful GTP protocol, it features a nice undo command which makes undoing moves a breeze. Unfortunatly the original implementors forgot to add a redo command, in fact the GTP-compatible Go engines don’t know this concept. Ergo one has to track all the different moves (moves, passes, resigns, generated actions, …) externally and re-apply them if the user decides to jump through the command/action/move history. But Qt came to the rescue, the Qt undo framework is a breeze to use and saved the day here. Long story short, here is a little screenie showing the obvious:


Doesn’t that look a bit like dock widgets? Yeah, I decided to replace my first design of using different screens to show game state with a more modular approach. Screen-based meant something like having a SetupScreen responsible for setting a new/loaded game up and a GameScreen for handling board display/interaction/… (and ErrorScreen, you get it). Altough this worked quite well it raised some issues here and there. It first of all results into a static user interface which is non-customizable. Second thing is a lack of seperation of concerns in the codebase (in contrast to what was originally intended by using that screen concept). Namely which class/screen is the owner of the Go engine backend class and the running Go engine? Also some doubled code for house-keeping … Moving away from this approach to using QDockWidgets took around 3 hours (a nice example how Qt enables rapid application development). Actually I had to throw away only little portions of code because all visual stuff was created with Designer, so bits and pieces of those UI files just had to be copied into smaller distinct pieces. So the new approach is laid out like this:

  • Kigo::MainWindow class which is _the_ GUI class with it children
    • Kigo::GameView class (QGraphicsView subclass) as a widget to interact with the user
    • Kigo::GameScene class (QGraphicsScene) only depends on a GoEngine and is responsible for giving it a (themed) visual representation
    • Kigo::GoEngine class, the GTP abstraction and responsible for game interaction, etc.

All those little dock widgets are then shown or hidden based on game state and allow for great extensibility in the future (The game editor feature for example). Enough bla bla, here is another screenie:


Seems like I forgot to mention the most important fact, playing against a Go engine is possible now. Strange as it sounds but I finally got this right and enabled it in the GUI part. So you finally can play Go with a Go game, how awesome is this?

Having this sorted out there are still some things marked as TODO. Being able to let multiple go engines fight each other is still in the pipeline, I already had a solution here but I want to have it implemented in a clear way, so you won’t see this feature in current trunk. Multiplay via GGZ or the more traditional go servers will definitly happen after a first release. And yes, there will definitly be a release in time for KDE-4.2, probably in extragear.
Therefore I plan to get in touch with the kdegames guys a bit more to get things sorted out (sorry guys, internet connection in my current location remains mostly a wish, but I promise to do better).

Next thing to concentrate on is to get this backend configuration right, as well as fixing some usability glitches. And a better icon would be cool, the one I stole from KReversi (and which seem to be not used any more) is nice but a bit too green, I would be glad if someone could turn this into a more wooden (resembling a go board) appearance.

Expect these changes to be pushed into SVN in the following days…


8 thoughts on “On retracting moves …

  1. awesome 🙂
    cgoban gets on my nerves, it’d be great to be able to connect to the server with a nice well-designed kde program someday. 🙂

  2. .. shares some ideas with Kigo. In fact to GoEngine class is a blend of my former (PyGTK) implementation with some parts of the qgtp.[h|cpp] files of qGo. In fact qGo is a Qt-3 application, I wanted to use KDE technology (this projects doubles as an exercice for me) and off course Qt-4. qGo served as a nice inspiration but as you already stated, development ceased and in my opinion the code base rather evolved during the years than following a specific design. After I made my experiences with PyGTK (the working remains of “GnomeGo” are still available if someone wants to continue this), I wanted to have a clear, expandable and simple implementation and to me it was obvious that this was not possible with a simple port.

  3. Sorry to question this here. First, sorry about my poor english: i’m Brazilian. Second: I’m very interested on KIgo and checked out the source from subversion. But I didn’t know how to start the compiling. I saw CMake, but no Makefiles. PS: I know C/C++ and something about Makefiles. Any walkthrought? Thanks a lot!

  4. Ok, the following should work when you have KDE-4.1.x or KDE-4.2 Beta installed. Install cmake and libkdegames-dev (I asume a Debian-based distro here), the latter should pull in all other KDE/Qt libs necessary. Check out the most current Kigo source (I’ll upload a massive update after the holidays, I have something nice in the pipeline ^^) jump into the directory. In there create another directory “build”, change into it and type “cmake ../CMakeLists.txt” (basically an out-of-tree build here). This should work, but I recommend waiting a bit more, I plan to push this thing into an usable state to have then a packages for the next major distro-upgrade round…

  5. Okay… I’ll try and if not work I’ll wait for the Debian Packages (i use Debian Lenny Testing with KDE 4.1 backports). PS: Are you planning kigo to have l10n e i18n? If so, you could lean on me to translate it to Portuguese Brazilian

  6. might take a bit more time than expected, i’m currently quite busy writing a seminar paper, but I already have a bigger patch lying around here to be committed soon…

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com 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