Bloggin’ it up

Yesterday in the #kde-edu IRC channel, I witnessed the following conversation:

<piacentini> Another guy was consterned when I told you about KEduca not being in 4.0
<piacentini> He says he used it already for test with more than 45,000 students
<annma> oh
<annma> really?
<piacentini> And he changed his lecture when I told you this
<annma>
<piacentini> Gonna tell people that they need to colaborate, participate, or products can die
<annma> yes
<annma> whenever we looked at KEduca it did not work
<piacentini> I hinted (he works on a government) that he could even sponsor someone to work on it
<annma> but if we had use cases we would have fix it
<piacentini> Yes, I asked him for a list of things he likes, things he does not like, what he uses
<piacentini> And we talked a bit about it
<piacentini> He says (really) that he estimates that the state has saved R$ 15.000 in printing when he switched to KEduca tests
<piacentini> That is about U$10.000
<piacentini> per quarter
<piacentini> Notice that these are tests applied on free courses to a poor community, where they train people in free software and also in other stuff like mechanics, cooking, etc
<piacentini> So for this sort of feedback events like this are good imo, hopefully he will get back to me, and we can use this story to motivate someone to port KEduca to KDE4, and address its shortcomings. I got moved, but my plate is more than full for now

And well, I can say that this story did motivate me and I immediately started work on porting KEduca to KDE4. Now somehow, it had managed to evade any sort of porting effort thusfar so my work was more than cut out for me.

However, a day later and I’ve got the main application compiling and here’s the proof:

As you can see, the menubars are a bit screwed (in fact the Settings and File menus don’t even do anything) but that’s all just a matter of time I’m sure.

Now of course, it’s too late for KDE 4.0 but I’ll try to get it in shape for 4.1 and make some people in poor communities happy

Recently I’ve been working on some library classes for the KDE4 Games module. Firstly a high score table system and more recently extending Mauricio Piacentini’s KThemeSelector to use KNewStuff2 and make it usable by any game in the module.

This is the first time I’ve worked on any sort public API so it was interesting to see the way I do it compared to the rest of KDE/Qt.

Now I’ve never actually used Ruby. All I’ve done is read a few articles on it and look at a tutorial or two. I can’t remember anything substantial about the language but the one thing that has stuck in my mind about it is it’s design philosophy that is most often talked about. That is the way that it caters for the majority of uses by default. By that I mean most classes that are ever written will, for 90% of the time, only be used in one specific way. With maybe a few lines of code that are the same every time the class is used. It is only 10% of the time that the class is used in a way that is out of the ordinary. Because of this rule, API should be tailored towards making it really easy for the 90% of people who only want to do basic things.

Now this sounds like very good philosophy to have when writing an API which is providing an easy way to implement a highscore table or a theme loader. Most tasks should be possible in three lines of code and only the unusual tasks (like custom score fields or loading themes from a different directory) should require more. I think I achieved that with KScoreDialog.

Incidentally, hello PlanetKDE.org! I’m Matt Williams (milliams on IRC/SVN). I’ve been actively hacking KDE for about 6 months (though I’ve been helping out with various other bits for a while before that) now and I’m currently working on kdegames and doing a little bit of work on Plasma.

I feel a list is in order:

• KSquares is now in KDE Games and so will released in KDE 4.0.0 Alpha next Monday
• I’ve been doing lots of library work for libkdegames. Stuff that no-one will ever notice
• I’ve got four exams in the coming week so that’s annoying
• Skiing was awesome
• S.T.A.L.K.E.R. is also awesome

Phew, this lazyman blogging is much easier

Yesterday, I massively refactored KSquares. Basically, there was too much code in the QGraphicsScene class which was handling game data. For example, it was responsible for checking for any completed squares every time a new line was drawn. As a result of this there were signals flying everywhere - mostly to KSquaresGame, the class that’s supposed to be the game controller - which was nastily messy. I moved all game specific code into the KSquaresGame class and so could vastly simplify the API of both classes. A side effect of this refactoring is that it makes it easier when I come to add network support.

All this refactoring got me in the mood to do a bit more work on Sparkle. The code that’s currently in the repository was always intended to be rewritten (maybe several times) and I figured today would be a good chance. I feel at the moment, the code structure is too complex. I need to plan better how everything is going to fit together and how to most efficiently describe the relationships between different objects.

P.S. If anyone’s tried KSquares, I’d love to hear what you think of it as I’ve had no feedback yet

I’ve got myself a SVN account on the KDE repository and have imported KSquares. It can be found at http://websvn.kde.org/trunk/playground/games/ksquares/. If you want to build it you’ll need KDE4 and you’ll have to checkout the whole playground/games folder in order to get all the CMakeLists.txt files.

Okay, loads has happened since my last post.

I started work on a 2D physics engine. You can see what I’ve managed so far at its Sourceforge page. The code is all in subversion atm. It’s certainly a WIP and won’t really blow anyone’s socks off since all it really does at the moment is crash

Also, in preparation for doing some proper KDE work I decided to learn my way around the API a little. With the help of annma’s KAppTemplate/kapp4 I managed, in only a day or two to write a little game that uses KDE4. It’s based on that game ’squares’ that is another great timewaster in the same category as Noughts and Crosses. Version 0.1 can be downloaded from this site but be aware that it will require KDE4 and CMake etc.

Now it’s technically been 8 months since I released version 0.1.4 so this is rather overdue.

To be honest there aren’t a whole lot of new features added. Undo/redo is still barely functional and will likely crash the program :S. What has been added is finally the possibility to resize the game area. Not only that but the underlying code has been rewritten so that the grid lines will draw correctly even on windows/mac.

Apart from the code changes I have also changed the build system from standard qmake to CMake. The main reason for this is that now the Boost libraries are used (in a very minor way) I needed a cross platform way to find the libraries etc. Now that I understand CMake that little bit more I should be able to help Dave when he moves Thermite to CMake (though he has the CMake book so he’ll probably be the one helping me!).

I’ve been doing some reading up on C++ and so for the next version I am going to be doing some major refactoring of my code to make it faster/more elegant/more correct.

You can download the sourcecode from my download area and get general information from here.

Ok, I’ve ‘finally’ got round to adding all the functionality of my old Xoops site to this new Joomla one. There’s now a page describing kudoku, a downloads area and a link archive. Now the hard part of setting them up is complete, hopefully they’ll slowly get filled in over time.

On another note, I’ve picked up hacking kudoku again particularly playing around with Qt’s layout system. It shouldn’t be long now until version 0.1.5!