New blog address

My blogger account is not getting along well with Planet, apparently… The last few posts did not show up, so following a suggestion by clee I am  moving to a LiveJournal account. Fingers crossed 🙂 If all goes well I will be able to report from FISL in the next couple of days.

Old entries can be found here.

KGoldrunner animation

Last week I committed some code changes and artwork for KGoldrunner to SVN. This is something I was planning to do for some time, but the lack of good open source tools for animating SVG directly slowed me down quite a bit. I ended up using a commercial package (ToonBoom) to prototype the runner animation: it does not support SVG, but it has nice support for skeletal structures, so you draw the body parts and then animate their position using pivots, in a process usually called cut-out animation.
But ToonBoom can not export the results directly to SVG, only to Flash, or image sequences… So in the end I kind of used it only for prototyping the movement, and then exported everything as a PNG strip, just for reference.
In the end, I re-did all the body parts in Inkscape, and used groups to structure the runner as a 16-segment figure. These are cloned and positioned/rotated to generate the frames, so hopefully it would be easier for other artists to add variations of the character: just edit the original shapes, and the clones will update automatically, keeping the animation more or less intact.
Here is a screenshot of the runner and enemies frame sequences in Inkscape: each one has 36 frames at this time:

And here you can see the enemy carrying a gold piece more closely, very funny:

There is still some work to do, we are going to integrate new backgrounds and other elements to the final game before KDE4 is ready. Notice how the runner and enemies are small in the final in-game version: this is one of the reasons why it was so difficult to animate them, as small details are lost. Checkout kdegames in SVN to see them in action.

Ah! And of course, the old themes are still there, for the nostalgic.

Shisen-Sho updates

I just added the configuration dialogs of libkmahjongg to KShisen. Players can now select their preferred tilesets and backgrounds, of course all rendered from SVG. With libkmahjongg both applications can now re-use the same artwork, and this is also available for any future game that uses mahjongg tiles.

Next step? Maybe integration with KNewStuff2, we will see.

KShisen screenshot:

Background selection, using the new chinese landscape contributed by Eugene T. All meta information is ready for translation, including the background and tileset names. The oxygen icons for the config pane are not ready yet.

+1.5 million KDE desktops

According to recently published data, 8.3 million new computer systems were sold in Brazil last year. And of these, 18% shipped with free software (OS, desktop and applications). So we are talking about 1.5 million new free software desktops!

More data here (in Portuguese.)

What the story does not tell is that (last time I checked!) all 11 distros that shipped pre-installed in Linux systems in Brazil used KDE as the default desktop. Neat!

KDE4 dev dependencies

I was rebuilding a clean Kubuntu install just for compiling KDE4 apps, and this time I actually took notes of the packages needed to build the following modules, which are the ones I need for basic kdegames testing:

strigi (apparently will be required in a few weeks for kdelibs)

Starting with a default Kubuntu Edgy install, launch adept and request the following packages


(edit: for strigi, add also

libclucene-dev )

This assumes qt-copy is being built with opengl support, which is something not strictly required, iirc. Just keeping the list here in case I need it in the future, instead of waiting for a build failure to hunt/install a new package.

Of course, now that I have written it down I am sure someone will tell me that all I need is some sort of meta kde4-devel-libraries package, which already exists somewhere!

Blur using SVG filters

The Inkscape team has just released version 0.45, and it includes initial support for SVG filters. The first one implemented is Gaussian Blur. Raquel Ravanini was quick to try it in KMahjongg tiles. Notice that we already have shadows, but these are currently made of several gradients put together. They look good, on most cases, but the seams are difficult to manage. This screenshot shows the new tile using a simple Gaussian Blur filter (right), and our current approach (left).

In the case of this particular tileset the difference in rendering is not significative, but having support for the SVG filter in Qt/KDE would make the life of the artist easier, and the filesize smaller as well. Sometimes it is difficult to achieve good results at larger resolutions using multiple gradients. Zoom in and notice the small gaps in the shadows apparent in this screenshot of the classic tileset:

(Before you comment on it, of course this is just an example, we know about the gaps, there is still work going on on the Classic tileset and some adjustments are going to be made before the final version to correct them.)

Unfortunately, at this time QSVGRenderer apparently does not support SVG filters. Rendering this svg file with Qt 4.2 gives us the following result

I must mention that I really did not expect it to work yet, of course. Firefox and other SVG viewers do not work as well. Support for filters is expected in Firefox 3.0, however.
It appears that SVG filters will become increasingly popular in the near future due to Inkscape, as they solve real design issues and help keep the filesizes manageable. It is probably not a trivial feature to implement, but hopefully future versions of QSVGRenderer will include support for this technology. Maybe in time for a KDE 4.1? Maybe if we bribe Zach, or clone him?

KDEGames updates

Here is a brief summary of the most recent meeting of the KDE Games project. The meeting happened last Thurday, February 1st, 2007, and approximately 20 people were in the #kdegames channel.

The first topic covered was the current status of SVG conversion and art revamp. Work is progressing on several games, including KNetwalk, KBlackbox, KShisen, KGoldRunner and Kolf. Other games like Konquest and KSpaceDuel are also in the queue, but maintainers outlined the need for more artists. Currently johann_ol is working on several games, and a few others (KMahjongg, KShisen) have received help from artists. But several games could use some help. In some cases (like KGoldRunner) the maintainers are implementing placeholder art, but we really need a process to attract artists and let them collaborate with the project. So a “KDE Games Call for artists” drive is in order. Discussion is currently in progress at the kde-games-devel mailing list about how to communicate clearly our needs to artists. During the meeting it was observed that probably several artists could help, but few of them have the time and skills needed to build KDE4 at this time. So we need to find a way to document clearly the format of SVG data we expect for each game, and make it possible for artists to create new themes and visuals based on placeholder data.

We also discussed the current state of It was decided that for internal communication we can continue to use blogs and for now, but need some attention, as it is the primary channel of communication with end users. Of course, in order to update the site we need volunteers. So if you want to help, please post to the kde-games-devel mailing list. Albert can commit content for now.

Then we talked about new games that were invited to join the module. KSquares is already in playground, and it is moving to kdegames. KSudoku will be migrated from its current repository to KDE SVN in the next couple of months, initially to playground. Discussion on KisrK will resume on the mailing list, as Kleag could not attend the meeting.

Next on the agenda was GGZ support and updates. Roger and Josef from GGZ were present, and a GGZ-enabled version of KReversi will be ready very soon. This will hopefully serve as a proof-of-concept implementation, making it easier for other maintainers to add multiplayer support to the games as well, using GGZ. Also, kggzmod and kggzgames are likely to be moved to KDE SVN soon.

Some people requested a slightly later time for the next meeting, and others requested a longer meeting, as one hour was considered too short for all we have to cover. So the next meeting will be at March 1st, from 8PM to 10PM, UTC time.

IRC non-meeting

In the last kdegames IRC meeting we all decided to skip the January 1st monthly-meeting, for obvious reasons. Someone then suggested that we should schedule an informal gathering to the second Tuesday of January. But we forgot to remind everyone in a timely manner, so what follows is the log of our quasi-meeting, pretty much myself chatting with Josef 🙂

I am just posting it by request. Nothing terribly interesting to see here, move along …

[Tue Jan 9 2007] [17:00:25] it’s not too crowded yet
[Tue Jan 9 2007] [17:01:37] i’m going
[Tue Jan 9 2007] [17:01:38] sorry
[Tue Jan 9 2007] [17:01:45] i have business dinner
[Tue Jan 9 2007] [17:01:58] save the log and i’ll try to read it tomorrow
[Tue Jan 9 2007] [17:02:03] Join teprrr has joined this channel (i=tpr@kde/developer/rytilahti).
[Tue Jan 9 2007] [17:02:07] log will be saved for sure
[Tue Jan 9 2007] [17:02:11] bye!
[Tue Jan 9 2007] [17:02:12] tsdgeos: eat well
[Tue Jan 9 2007] [17:02:21] piacentini: thanks 🙂
[Tue Jan 9 2007] [17:02:24] Quit tsdgeos has left this server (Remote closed the connection).
[Tue Jan 9 2007] [17:02:53] josef: let us chat for a while then, apparently the others are lurking
[Tue Jan 9 2007] [17:03:00] yeah
[Tue Jan 9 2007] [17:03:22] Regarding the KConfigDialog issue, I think it should be used if possible…
[Tue Jan 9 2007] [17:04:17] the new config dialogs for KDE 4 all look nice, maybe there could be some common config elements for games
[Tue Jan 9 2007] [17:04:21] But I am trying to use it for libkmahjongg (selection of tilesets and backgrounds), and it seems to be tricky…
[Tue Jan 9 2007] [17:04:21] such as player colours, names, etc.
[Tue Jan 9 2007] [17:04:29] agreed
[Tue Jan 9 2007] [17:04:52] I was designing a standalone dialog for tileset selection, to be shared between Kmahjongg and Kshisen
[Tue Jan 9 2007] [17:05:07] ah, so libkmahjongg already provides such a card deck selector…
[Tue Jan 9 2007] [17:05:10] much like the carddeck selector in libkdegames
[Tue Jan 9 2007] [17:05:30] Join slougi has joined this channel (
[Tue Jan 9 2007] [17:05:40] But now I am thinking about formatting it as a page widget, to be inserted into a KConfigDialog
[Tue Jan 9 2007] [17:05:56] is it intended to replace that? I mean, we shouldn’t hesitate to put better things into libkdegames so it gets a wider use outside of KDE
[Tue Jan 9 2007] [17:06:16] Actually the one I am coding is only for tileset selection at this time
[Tue Jan 9 2007] [17:06:26] ah ok
[Tue Jan 9 2007] [17:06:27] But I guess something similar should be planned for card deck
[Tue Jan 9 2007] [17:06:29] Join christoph4 has joined this channel (
[Tue Jan 9 2007] [17:07:04] for my own games I provide very little configuration atm but I guess this should be changed
[Tue Jan 9 2007] [17:07:13] One of the reasons for moving code to libkmahjongg is to let any other game that wants to parse/render mahjongg tiles use it
[Tue Jan 9 2007] [17:07:50] Well, my point is that if possible we should make game configuration as similar to the user as possible to configuration of any KDE app
[Tue Jan 9 2007] [17:08:26] there’s also the question of global config items for all games, such as server settings or maybe sounds (if someone wants to play without sound in office but still not deactivate sound every time)
[Tue Jan 9 2007] [17:08:51] That is another level. How do you propose this should be handled?
[Tue Jan 9 2007] [17:08:58] or a player photo/avatar, which could be read from KDE’s identity settings but this might not be enough
[Tue Jan 9 2007] [17:09:04] I have no clue 🙂
[Tue Jan 9 2007] [17:09:37] what I’d like to avoid is the “kontact issue” which provides two config dialogs per application
[Tue Jan 9 2007] [17:09:47] one for e.g. kmail and one for kontact
[Tue Jan 9 2007] [17:09:52] I see
[Tue Jan 9 2007] [17:10:06] The card deck selection in libkdegames is global, btw
[Tue Jan 9 2007] [17:10:08] (and one for shortcuts and one for filters and …)
[Tue Jan 9 2007] [17:11:22] what about Gtk+ integration: should we provide some way of letting them know what the user’s preference for carddecks is?
[Tue Jan 9 2007] [17:11:46] Well, the problem is that the card deck format is not the same iirc
[Tue Jan 9 2007] [17:11:57] And at the moment kpat is not even using the old selector
[Tue Jan 9 2007] [17:11:58] ‘t should be :/
[Tue Jan 9 2007] [17:12:45] coolo will probably code some form of card selection, and hopefully it will be useable by kpoker and lskat
[Tue Jan 9 2007] [17:12:51] but this is only speculation on my part
[Tue Jan 9 2007] [17:13:28] I still consider it worthwhile to have a well-defined card deck format, e.g. a flat directory with some SVG files and some meta information
[Tue Jan 9 2007] [17:13:56] sure, agreed
[Tue Jan 9 2007] [17:14:32] For mahjongg tiles I am documenting the format, and hopefully it will be shareable
[Tue Jan 9 2007] [17:14:54] very good
[Tue Jan 9 2007] [17:15:25] another TOC for today is SVG conversion, so I guess we’ve already partially arrived at this discussion 🙂
[Tue Jan 9 2007] [17:15:45] yup. Too bad johann and dimsuz are not here, but it is january
[Tue Jan 9 2007] [17:16:52] hm… so skip this point?
[Tue Jan 9 2007] [17:17:07] Is anyone else alive here 🙂 ?
[Tue Jan 9 2007] [17:17:44] As for me, I have implemented the SVG graphics in KShisen (actually sharing the Kmahjongg implementation)
[Tue Jan 9 2007] [17:17:51] But KMines is still on hold
[Tue Jan 9 2007] [17:18:34] I’ve recently fixed my KDE 3 SVG loader to work correctly on little-endian machines, and am looking forward to drop it… but it helps me to already be able to use SVG graphics
[Tue Jan 9 2007] [17:18:49] Did you and dimsuz have time to sketch anything regarding GGZ support in kdegames?
[Tue Jan 9 2007] [17:19:24] Join stampede has joined this channel (n=henrique@
[Tue Jan 9 2007] [17:19:41] yes, the README.ggz-kde4 document was updated and contains some nice progress… for example, full CMake support was added, and some usefull classes such as for reading binary packets which integrate nicely with the existing libraries
[Tue Jan 9 2007] [17:19:45] hi all
[Tue Jan 9 2007] [17:19:50] hi stampede
[Tue Jan 9 2007] [17:20:04] great!
[Tue Jan 9 2007] [17:20:27] there’s also a patch for KReversi, but it doesn’t work yet
[Tue Jan 9 2007] [17:20:39] once KReversi is done, the rest will follow easily 🙂
[Tue Jan 9 2007] [17:21:22] oh another thing…
[Tue Jan 9 2007] [17:21:33] we’ll release by next week
[Tue Jan 9 2007] [17:22:14] how is it going in regards to gnome games?
[Tue Jan 9 2007] [17:22:58] well, gnome games are still looking for a server… so in addition to theirs (which is always offline) they’re using ours but it won’t help ours once gnome is doing their release
[Tue Jan 9 2007] [17:23:07] so we in turn are looking for better hosting
[Tue Jan 9 2007] [17:23:41] I still got very little input from the player communities if they want to be split or not
[Tue Jan 9 2007] [17:24:00] ideally imo they should be consolidated
[Tue Jan 9 2007] [17:24:06] but there is the problem of server costs
[Tue Jan 9 2007] [17:24:15] for example, it would make sense to put all the cards players on one server, since they’re kind of a community on their own, but there are also some players who’d like to play any game
[Tue Jan 9 2007] [17:24:59] the cards players who were at MSN before have very low expectations to technology, whereas KDE/GNOME folks have much higher ones
[Tue Jan 9 2007] [17:25:58] so in summary, there are two paths to take at the same time: working on better distributed gaming, and looking for a server sponsor
[Tue Jan 9 2007] [17:26:33] distributed gaming like in a p2p setup?
[Tue Jan 9 2007] [17:27:11] not exactly, since for tournaments etc. you still need a central instance
[Tue Jan 9 2007] [17:27:40] to take off some load, games can run on other hosts but their statistics do not count as trustworthy then
[Tue Jan 9 2007] [17:28:01] and administration is not easier if one has a couple of hosts
[Tue Jan 9 2007] [17:28:51] Switching the topic a bit, I guess what we could do (in general) is to implement concrete examples for some of the ideas we raised in the past couple of months
[Tue Jan 9 2007] [17:29:16] For example: I am trying to implement a better configuration dialog for Kmahjongg
[Tue Jan 9 2007] [17:29:32] In the hopes that it will be scrutinized by others, etc.
[Tue Jan 9 2007] [17:29:39] Same as we did in SVG, basically
[Tue Jan 9 2007] [17:29:56] And regarding GGZ, I believe the starting step is really the KReversi effort you guys are doing
[Tue Jan 9 2007] [17:30:25] yup, dimsuz wanted to help so I hope I can soon give him some better material
[Tue Jan 9 2007] [17:30:36] Join [ksudoku]Josel has joined this channel (
[Tue Jan 9 2007] [17:32:39] Quit [ksudoku]Josel has left this server (Client Quit).
[Tue Jan 9 2007] [17:32:42] Well, I think we covered the agenda…
[Tue Jan 9 2007] [17:33:11] pretty much so
[Tue Jan 9 2007] [17:33:49] K, I am signing off then. We should do a proper meeting in February, don’t you think?


During the past week I worked on separating tileset and background handling from KMahjongg into a new library in the kdegames module (libkmahjongg.)
The goal was to make it possible to reuse this code on KShisen, and possibly other games that might need to render standard mahjongg tiles in the future.

There is still work to do, but the first results of this effort are now in SVN, and KShisen for KDE4 is already using the new shared code.

Here is a screenshot showing the KDE3 version:

Below you can see two different SVG tilesets for KDE4. The first was contributed by Robert Buchholz, and improves on the classic style used in KDE3:

And here we have KShisen using the new KMahjongg tileset, contributed by Raquel Ravanini:

Hope you guys like it. As a side effect of this effort rendering speed has also improved substantially during the last couple of weeks, due to incremental changes and optimizations. Game window resizing (including SVG recalculation) in KShisen now redraws in more or less the same time that it took the KDE3 version to draw the PNG-based theme. Cool.