KBoard is dead. Long live Tagua!

We finally made a decision, and named the project Tagua. Thanks to all the people who suggested possible names, and expecially to Riccardo Iaconelli who came up with the definitive one.
I’m now doing a global s/kboard/tagua/g on webpages, code, tracker, cron jobs, git repository…

Ah, yes, I forgot to mention that we moved the project to git when we resumed the development at Akademy. There has been a long thread on kde-core-devel discussing the adoption of git by subprojects, and there emerged that moving away from the KDE svn (though apparently discouraged) does not mean parting from the KDE project. I’ll probably talk about our experience with git in a dedicated post.

So, if you want to try the development version of Tagua, either grab a nightly snapshot (temporarely located here), or clone our main repository:

git clone http://repo.or.cz/r/tagua.git

KBoard: an update

KBoard is a project by Maurizio and myself for a generic board game application. It started back in October 2005, and progressed slowly but steady until the end of 2006. After then it was left starving on the playground, basically untouched until a few days ago.
After a prolific discussion at Akademy, we are now back developing KBoard at full speed. Here are a couple of screenshots showing our progresses so far:

Compare them with the old screenshots and you’ll see how much has been done in just a few weeks: the main layout and the clock are now themable via Lua scripts, just like the chessboard and pieces.
I shall thank Maurizio for this astonishing work, and generally for his invaluable Lua theme loader, which is one of the finest pieces of code in KBoard.

By the way, most of the recent changes are actually invisible to the user, and concern the API used by the graphical interface to communicate with game plugins (called variants). I recently worked (not that much) on the animation stuff, and ported three games to the new API. Maurizio made the whole refactoring of the code using the old API at akademy, and revised the concepts around the pool (i.e. the place where captured pieces end up in games like Shogi and Crazyhouse).

We plan to release KBoard 1.0 by the end of the year. It might be an optimistic estimate, but if we continue to work with this speed, it should be actually possible. There is a lot of things to fix, but the planned features are almost all there. Needless to say, any help (developers, artists) would be really appreciated.

At the moment, our biggest dilemma is the name. We decided that the name should be changed (KBoard is ugly and doesn’t even make clear what the application is about), but after a whole day of awfully poor proposals, we still have to find a decent alternative. So you if have a nice name in mind (not necessarily starting with k, think about Phonon, Plasma, Solid… those are good names!) please tell us!

The “covariant argument problem”

Working on KBoard I’ve been forced to face great number of design problems, which I’d say have all been solved quite neatly, with one big exception: the covariant argument problem, hereafter referred as CAP.

This dreaded problem manifests itself when trying to abstract a great amount of functionality from a system using a set of interfaces (i.e. abstract classes with only pure virtual functions) so that client code can add custom behaviour to the system by implementing all these interfaces.
Nothing new, you’d say, that’s exactly the purpose of abstract classes and interfaces, but the difference here is that we have a set of (possibly interdependent) interfaces that we would like to implement at once.
To better explain the situation, I need to set up some names, so suppose you have three interfaces IA, IB, IC, and two different and completely incompatible incarnations A, B, C and U, V, W. Suppose further that IA has a method foo taking an IB as a parameter. When implementing the ABC incarnation in client code, you need to preserve the signature of foo, so you’re forced to accept any IB as its parameter, while of course only B’s have a meaning there. This is the fundamental dilemma of CAP.

The story isn’t new: it’s been studied in great detail by type theorist and even addressed in real programming languages like Eiffel, but the subject is still somewhat controversial and I’m not sure that a clean solution really exists, even accepting a language switch (not that I would second it :)).

Our solution consists in a layer of ugly (and by ugly I mean very ugly) template code which does the work of type conversion and type checking that the compiler is unable to do. The strong point of this solution is that the client never needs to delve inside this messy kludge, and can simply implement the required functionality by creating classes complying to implicit interfaces.

If you are curious to understand how this really works, you can find a short description here, and obviously the code, which is only one header file (but ignore the comments, they’re ancient… yes, I know they should be kept up to date…).

XML configuration files for KDE

Since KBoard needed a powerful hierarchical configuration system and QSettings was too limited for our needs, we decided to implement an XML-based configuration framework from scratch.
Hence, Settings was born.

Today, I’ve decided to write a bit of documentation for Settings, and to eliminate all references in it to the rest of KBoard, so that other KDE (or Qt) developers not satisfied with QSettings/KConfig can benefit.

You can find the code and a sketched documentation on the kboard wiki.