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 (email@example.com, 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.