apaku

I’m Mentor again this year in Google’s Summer of Code. I’m again mentoring a KDevelop4 project, the title is: xUnit test harness for KDevelop4.

Manuel Breugelmans was chosen do to the project, he’s a student at the university of Antwerp in Belgium. He’s a new developer in the Qt/KDE/KDevelop world, but has already quite good C++ skills. Apparently he also has quite some knowledge about unit testing as he’s writing a tool to analyze xUnit code and visualize it.

The project itself aims to provide some infrastructure to ease the creation and execution of tests within KDevelop4, the most important deliverables are stub test template creation, report and coverage framework and a graphical test runner. The current plan includes supporting QtTest, CppUnit, Check and PyUnit.

I’m confident this will be a success as Manuel has already dived into possible solutions for some things, including contacting authors of existing test-runner tools to talk about collaboration.

I just got back home from the hackathon (well, I picked up keys for a new appartment also, so it wasn’t a 12 hour trip back). Its really sad that its now over, it was a really great time meeting all the people and putting faces to the nicknames. I would’ve liked to stay longer with all of the hackers.

We did quite some progres this week, trying to fix Ui problems (didn’t get around to all of them), making C++ support work more reliably, improving cmake support with language features, changing some API in some places to have more freedom and improving the debugger a lot. I was able to use KDevelop4 for hacking in the last 4 days which feels really great and finally forces us to really fix all those small annoyances.

I’m looking forward to more commits in the upcoming weeks, as I think everybody got quite a motivation boost.

And a big thanks to Harald for organizing the meeting and finding sponsors for it.

As I’m just re-compiling KDev4 I’ve got a few spare minutes to blog.

So we had a really great weekend with lots of interesting speaks and even more discussions about what we want/need to have in KDevelop4 and how things should work. The todo-list got ridiculously large (which is good actually)

And right now everybody except Hamish (who got a bit sick after last nights “Schweinshaxe”) is hacking to bring KDevelop4 into a usable state. The User interface got large fixes and the C++ support shouldn’t crash so often anymore. Actually I noticed that a release build of kdelibs+kdevelop is a bit more stable because assert’s are ignored.

Personally its really inspiring to sit here within a group of 10 other geeky hackers and get something cool done.

Oh and btw. I think we can now invite interested “testers” to try out kdevelop4, I’m using it since 2.5 days now and it is pretty usable already, albeit a tad bit slow and crashy in debug-build. So I’ll either start hacking on workspace support now or also do my tad bit of boring Ui stuff - not sure.

So, I thought it would be nice to eat fried potatoes tonight. And after the peeling came the slicing. Unfotunately part of my thumb got under the slicing knife (got such a nice tool with variable sets of slicing knifes and a  plastic bowl to catch the slices). I guess I don’t need to mention the blade was pretty sharp, clean cut about 2 millimeters of flesh.

Thats how I came to write this entry with just my left hand and I don’t like that.

Yes, its that time of the year again. Time to get your creativity out and find some nice things to hack on for Google’s Summer of Code. Looking at the ideas page on Techbase you’ll find only one SoC idea for KDevelop, but we already discuss 3 other possible projects. These projects are ideas that originated from students, which has proven to be the most successful way of getting a SoC project finished. So for this year we’d like to see more of those student-proposed ideas and thus keep the list of developer-proposed ideas short.

So if you’ve got some C++ experience and would like to work on a really great IDE, check out KDevelop3 or KDevelop4 and see if you can find something thats missing, something that can be improved (granted you’ll find a lot of that in KDevelop4). Or browse bugs.kde.org for our list of wishlist items. Last thing you could do is see if you find another IDE that does something awesome and try to implement that in KDevelop4.

If you have a nice idea for KDevelop4 then come to #kdevelop on irc.freenode.org or to our developer mailinglist (kdevelop-devel@kdevelop.org, subscription at kdevelop.org) and explain your idea. We’re happy to help with the details for the proposal and to give general feedback on how well suited the idea is for SoC.

Finally I’ve managed to finish the new cache for KDE card games

Until now the two card games that shipped with KDE Games in KDE4 both managed their own cache of rendered svg card decks. They’ve simply put the rendered images into png files in a special directory in $HOME/.kde4/share/apps. This has a few drawbacks:

• each card game needs to render the SVG at least once in the size needed
• wasted disk space if the same theme is used in both games
• a lot of similar code (almost duplicated)
• possibly some slowdowns because each frontside of the card deck was stored in a separate png file, so the game loaded 32-52 png files during startup

The new cache class is part of libkdegames, its called KCardCache and is rather easy to use. Simply store it as a member variable in your theme manager (or whereever your game currently renders the svg files) and then make sure to set the theme and proper size before asking it for cards. Some basic code may look like this:

mycache = new KCardCache();
KConfigGroup themeconfiggroup( KGlobal::config(), “Theme” );
mycache->setTheme( themeconfiggroup.readEntry( “Cardname”, “Oxygen (SVG)” ) );
mycache->setSize( themeconfiggroup.readEntry( “CardSize”, QSize( 60,80 ) );
QPixmap heart_ace = mycache->frontside( KCardInfo( KCardInfo::Heart, KCardInfo::Ace ) );

This would render the fronside for the ace of hearts into a pixmap which you can then use to draw on the board. Internally the cache uses the KPixmapCache class which was written specifically to cache pixmaps that need a lot of time for rendering. KCardCache uses different pixmap caches for each theme, but it allows to share the same cache among all kde card games that use it. So when you run KPatience and choose the Oxygen theme, the first time you run lskat and choose the same theme it already uses the cached images. Also KCardCache doesn’t need to read 52 PNG files because KPixmapCache stores all pixmaps in one data file instead of many.

As far as numbers go, I don’t have any. My feeling tells me that rendering during startup got a bit faster, but even if there’s no real noticeable speed improvement the other benefits weight quite heavily IMHO. Having the same caching code for all games, using a well tested cache implementation which is used all over KDE for icons and various other things and sharing the same theme-cache among all games is quite valuable in itself.

What I really love about myself is that for some reason I can’t stop making really stupid mistakes. I know everybody makes them, but somehow I’ve got the feeling I’m doing much more than anybody else.

Latest two occurence are bugs in KDevelop3.5.0 (one of them being in probably all releases since 3.4.0). I mean how damn stupid does somebody have to be to

a) use 2 variables, one named line the other named sline in the same function and

b) then mix those two variables up, which results in this: Bugreport 158236

The other one was pointed out on IRC today, stupid logic mixup with the same code in the else-part as in the if-part of an if-else. No wonder that you can’t turn off the warnings in QMake projects in KDevelop3.

I only catched the last one “by accident”, because I usually read the IRC backlog when I wasn’t sitting at the PC for a while. This one probably wouldn’t have ended in bugzilla as apparently some people think its not worthwhile to file bugreports against KDevelop3.

Thats however not true, especially if you’re not using one of the unmaintained parts. But even then, no bugreport is always worse than a bugreport that gets closed as wontfix (or fixed in 4.0 which is not yet usable on a wide scale). Obviously the problem here is to know which parts are unmaintained. So here’s a (probably incomplete) list:

fortran, java, php, python (this one will come back for 4.1), sql, csharp, bash, pascal, kdevdesigner (short note: use the normal Qt designer, you loose almost nothing and gain a lot of stability), valgrind, fileselector (known to be pretty buggy), distribution packaging, texttools, clearcase, perforce.

I’m not saying that bugs (especially crashes and the like) against these components will simply rot, I’m just saying its unlikely that they’ll get much attention as we simply don’t have many active developers and need to work on KDevelop4.

As a recent thread on kde-devel showed that nearly nobody knows about this, I thought I’d blog again about Sublime. Alexander already wrote two parts, here and here
and it was even featured in a commit-digest article. Obviously thats still not enough

So to put it short: If you want an IDEAl like user interface, that is dockwidgets (note: not necessarily QDockWidget) and a central editor area, then I invite you to have a look at Sublime Sublime. Its a Ui library thats solely based on Qt and kdelibs, even though its currently part of the KDevelop Development Platform. Its not yet finished, but it already supports quite some stuff that KDevelop3 had, including buttons for toolviews, automatic hiding of them, maximizing a toolview and “always show” option. The API is also prepared to support different Area’s (Eclipse calls this perspectives), so you can have different views into your application (for IDE’s this can be used to have a Debug, Code, Test and Design Area).

Once there’s another two apps using Sublime (and the Area stuff is implemented) we can even think about moving it to kdelibs, making it easier for apps that don’t need kdevplatform to use it.

Oh, I guess a small screenie is good (click for larger picture):

So finally the dot story is out, there’s going to be a KDevelop Hackathon in April in Munich. There’s even a “free-for-all” (as space allows) weekend to get to know us, or finally try to talk us into implementing your greatest feature wish for KDevelop

KDevelop “oldtimer” Harald Fernengel pulled this one off and so far Andras (quanta developer) and myself have their tickets booked. Alexander and Vladimir are also almost set, just need their Visa and hopefully Aleix exam plans allow him to come as well.

I’m rather excited, this will be the first time I’m meeting other KDE hackers - besides the handful of people at froglogic. Especially interesting to see how much fun we can have hacking on KDevelop4 full time

So if I’ve got you interested read the article on the dot for further information.

I’ve been working on this since christmas IIRC. A cache for all card games in kdegames (thats mostly two right now, but who knows what future will bring us). The idea is simply to unify some of the code that both lskat and kpat used to cache svg rendered card decks. Both simply put the resulting image as png into your $HOME to load from there. Both also had code to load png themes which need a mapping of “new style” element names - which are used as id’s in the svg’s - and the old style numbering scheme used in png decks.

I had hoped that moving the caching to KPixmapCache, which uses 1 large file for the caching instead of multiple files , would’ve speed up the rendering on size changes. But as far as I could measure with my stop watch it didn’t help much - if at all. However the new card cache did help to move common code into a central place in libkdegames, which reduces maintainence “cost” (in terms of time spent) and also allows to write new card games more easily.

I’ve more plans for such unifications, specially for handling the deck selection and finding out some information about cards.

The cache-code hasn’t yet been comitted, I still need to port lskat and get some review from the games people. Also there are one or two outstanding issues to be resolved.

And to get back to the topic: What took so long is figuring out how all the geometry calculations work, so I find the right spots to place CardCache::setSize() calls. For kpat it wasn’t quite obvious and me being geometry-wise challenged didn’t help either. I really can’t think this stuff, I have to write those formulas and calculations down and run it through a few example numbers.