skema 0.1

I have just released skema, a very simple tool I wrote to automate some repetitive coding tasks. Nothing fancy, just a ruby script that expands ERB templates in a directory, reading variable values from the command line, configuration files, or interactively.
Its purpose is similar to kapptemplate (it already includes a minimal KDE application template), but it may be faster to use for little things, and it is probably easier to create templates for it.
Here is a tarball for those of you who want to try it out. You can find a short tutorial in the README file that should be enough to get you started.
Here is a screenshot of skema in interactive mode while expanding the kapp template:

Some thoughts on git

As I mentioned in a previous post, we started using git for managing Tagua source code. There’s currently a lot of controversy in the topic of distributed versus centralized VCS’s, and I feel like expressing my own ideas, too.
I’m no git guru (yet), so please don’t get offended if I missed something in my criticism. I hope to generate a fruitful discussion, because I really think that the VCS is an important element in the development of an open source project.

Why git rules

• It’s decentralized. I fully agree with Linus on this point: the decentralized model is superior, for various reasons I won’t talk about in detail here.
• It’s simple. I don’t understand why people keep complaining about git being overly complicated. The object model is fairly straightforward, as soon as you stop thinking about revisions the cvs/svn way, and branching/merging is trivial.
• The object model is very well designed, flexible and useful.

Why git sucks

Well, git has a number of minor (?) defects, like portability issues, impossibility of doing partial checkouts (actually I think this is a problem with all the decentralized VCS’s) and stuff like that, but let me concentrate on those issues which are fundamental to git as an open source project, and are unlikely to be addressed in the future:

• It is written in (unreadable) C. I don’t want to start a flame war (really!), but browsing through git’s code is a painful experience. Huge .c files with tons of big functions with no apparent structure and almost no comment. Ubiquitous micro-management stuff for handling manually allocated buffers. In other words… a mess.
• It (ab)uses the UNIX philosophy. Do one thing, and do it well. Yeah, of course it’s a great idea, but maybe they shouldn’t have taken it too literally. I mean, if we talk about modularity and reusable components, I’m all for it, but it doesn’t mean you have to make a different executable for each task (even low level ones that should be invisible to the end user) and chain them together via text pipes and bash scripts!
• It’s not reusable by third party applications, at least not in any efficient/convenient way. If you want to build a higher-level abstraction over git (a so-called porcelain), you need to fork out every now and then to get input from git, and then parse its textual output. Yes, I know about libgit.a, but that’s not really usable as a library (half of git functions call exit on failure) and has no API documentation at all.

That said, I have to admit that most of its defects aren’t that important if you are just going to use it, and not develop it. However, using something you have problems inspecting and modifying feels a bit like using a closed source product…

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!

Canvas adapter and plasma

I’ve finally finished polishing the code of KGameCanvasAdapter, a hundred lines of straightforward code that stand as a bridge between KGameCanvas code and any QPainter based drawing system, including of course QGV.

The only test case for the adapter is a port of my kollision game to plasma. Porting was very easy: it was just a matter of having the MainArea class inherit from Plasma::Applet and KGameCanvasAdapter instead of QWidget. The resulting applet is not really a game, at the moment: it is just a box with bouncing red balls.
However, I think it’s a good test for both my adapter and plasma, since it can show how well plasma performs with CPU intensive plasmoids. Here is a short screencast of the kollision plasmoid in action.

The code is available in a git repository:

git clone http://kollision.ath.cx/plasma.git plasma

will download the whole patched plasma directory. To compile it, you should move it inside a kdebase/workspace working copy, so that it uses the existing cmake build system of kdebase.

KBattleship: almost ready

This week I’ve been hacking quite a lot on KBattleship, adding almost all required features: a decent AI, network play and sounds. While Riccardo is working on KWelcomeScreen, a library class inspired by this blog post by Johann, I’m going to make some minor adjustments, add small missing features like scoring, and if everything goes well I guess we can move the application to kdereview within next week.
This is a screenshot showing a game between the old KBattleship and my rewrite:

KBattleShip update

KBattleShip development is going on quite well. Johann did an amazing job designing the ships, and we also have to thank Robert Wadley for the ‘hits’ and ‘misses’. Here’s a screenshot:

Rewriting KBattleShip

This week I’ve started a complete rewrite of KBattleShip. I’m using KGameCanvas on an MVC architecture and it’s coming along quite well. Here’s a screenshot:

the ships are all scaled copies of the same one, because I’m waiting for Johann to finish the graphics

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.