KDE Traffic Aaron J. Seigo

Welcome to KC KDE! Important fixes continued to be made to CVS this week as usership, and therefore user feedback, swelled with the release of Beta2.

In these pre-release months, one KDE sub-project that has gained some legs is the KDE Usability Project. The email list is quite active and the website is undergoing several important changes such as the addition of a system for tracking usability-specific problems in KDE. The project has also adopted a "Usability App of the Week" program wherein a different KDE program or component is chosen each week to be examined and refined from a usability perspective. For those with a serious interest in usability who would be willing to write and maintain reports, contribute patches or conduct usability tests to gather meaningful statistics this project may be just what you are looking for.

We hope you enjoy this week's summaries of KDE development discussions and enjoy another week of Happy Hacking!
KDE-Games New Application

The KDE games package has several fun titles, but among them there has been one conspicuous omission: a good game of minigolf. Attempting to fill the glaring void Jason Katz-Brown wrote to the kde-games-devel list saying, My first real KDE game I've been working on is Kolf, in kdenonbeta/kolf. It's a fully-functional pretty-bug-free miniature golf game that so far has one 18-hole course. Courses can be edited on the fly and saved anywhere. There is also an English tutorial course (I'm still thinking about how to be able to i18n it...). If I perhaps finished another 1-2 courses, could this fit into kdegames in KDE 3.1? I would love suggestions on gameplay, the course, or new objects that could be added.

Kolf is slated for release with KDE 3.1 along with Atlantik, a board game that will be familiar to Monopoly fans everywhere, and Megami, a game of blackjack.

Art KDE 3 Animation

Though not the first to do so, Rob Kramer asked, I guess this has been discussed before, but I can't find much on it on google. The problem is that QT plays animated gifs according to the spec, so zero ms frame delay means *no delay* between frames. MS Internet explorer seems to have a minimum delay, and people design their gifs to play nicely in IE - so they play much too fast in konqi. Not only does this flaw cause some animated gifs to play too quickly but it also causes Konqueror to use 100% of a CPU while cycling through the animation.

David Faure replied, I know that Dirk sent a patch to TrollTech to make the minimum frame rate 1 ms (IIRC) instead of 0 ms, in QMovie. It seems it hasn't been applied yet. Lars Knoll of Troll Tech quickly replied, It will be in 3.0.2. And it's 10ms btw ;-) Qt 3.0.2 has since been released.

XML KDE 3.1

One of the many benefits of writing an application using the KDE libraries is the fast, powerful and reliable configuration setting classes. Those familiar with the internals of KConfig know that it is separated into front- and back-ends. To date there has been only one back end shipped with KDE. Tobias Koenig stepped up with a new KConfig back-end and announced its availability on the core devel list saying:

I've written a KConfigXMLBackEnd and it works already fine for me

...

I would like to see it in KDE3.1 when possible but by then the remaining problems have to be solved:

  1. In KConfig the use of KConfigINIBackEnd is hardcoded, so who to make it dynamic? Someplace there must be decided what BackEnd should be used by KConfig.
  2. When we are using dynamic back-end selection, how to differ the config files. atm both back-ends write data in different format in a file with the same name.

This prompted several inquiries with regard to speed, how to make the current .ini-style and XML files work well together, and what problems this XML backend would address that the current one doesn't. In the end it was decided that, while an excellent proof of what could be done, it didn't provide enough tangible benefits to be included in the main KDE distribution.

How long will the current configuration back end meet the needs of the KDE application developers and users? Only time will tell, but at least we know that KDE isn't permanently married to only one way of doing things as evidenced by Tobias' work.

CVS

The need for speed struck again when Lubos "The Optimizer" Lunak said:

see http://sources.redhat.com/ml/libc-alpha/2002-02/msg00107.html for details. In short, we're using malloc() very extensively, and a noticeable part of the execution time is spent handling dynamic allocations. Which means that malloc() should be very very fast, and if it's not, this affects overall KDE performance. The problem is we're linking against -lpthread, which makes malloc() use a mutex for locking (even though most KDE apps aren't actually threaded at the present time), and this makes malloc() to be not that very very fast.

I tried to do some benchmarks, and I e.g. managed to reduce time needed for fully rendering $QTDIR/doc/html/functions.html from 60s to 39s (30%) by LD_PRELOAD-ing a different malloc() implementation (Doug Lea's malloc), which I also tweaked a bit. Real world cases are a bit difficult to measure, but the improvement should be at least 10% everywhere.

This is only for glibc < 2.3 , I don't know about other systems. Also, with the current glibc CVS (i.e. the yet to be released glibc-2.3), malloc() uses already a spinlock instead of a mutex, and it has almost the same performance as my tuned malloc().

I'm going to include this malloc() implementation in libkdecore, and I already got ok from Dirk, as long it has to be explicitly enabled by a configure switch. It was already discussed a bit on IRC too. In case you have some thoughts on this, feel free to comment. I'll describe what I exactly want to do.

Lubos also noted that usage of this alternative malloc was optional at compile time through a configure switch in kdelibs (--enable-fast-malloc=[yes|no|full]). Lubos also mentioned improvements he was making to kmtrace to be make finding allocation-intensive areas of the KDE code base easier.

Some were concerned that this implementation would be inferior to the native malloc implementations on some platforms. Michael Matz answered this concern saying, Have no fear. As long as it's not proved, that it's faster for system X, it will not be anabled for X.

Icons Art Look and Feel SVG KDE 3.1

Some consider them the best things since full color displays. Some consider them a wasteful sucking of resources. Some see them as a necessary continuation of the "keeping up the with Jones'" cycle. Some just don't care. Yes, we're talking about SVG icons. Nikolas "Wildfox" Zimmerman felt strongly enough about them to write the code and announced the availability of SVG icons in KDE3 saying:

as promised here is the svg icon support :)

Patch url:

Screenies:

Those svg icons are the standard gnome svg icons, just for testing The svg icon loader is a rip-off of ksvg, because using ksvg directly would be bloat, it also includes a customized "lite" version of libart.

Will SVG icons be included in KDE 3.1? Tune in during the 3.1 development cycle...

KMail KDE 3

KMail, as shipped with the KDE3 betas, provides an excellent lesson for all application developers: no matter how many great improvements you make or how many user-requested features you implement, if you ruin the upgrade experience by not paying attention to the "simple" things like transitioning settings your users will not be happy. Unfortunately, the seemingly simple can often be difficult, not noticed or simply a drudgery to implement. Free software finds ways around such oversights, though.

In an email to the KMail development list Ingo Klöcker said, the attached perl script together with the small change in kmail.upd (and Makefile.am) will upgrade the SMTP/sendmail configuration during the KDE 2 -> KDE 3 upgrade. With these patches and users continuing to test (and speak up when necessary) the upgrade experience from KDE2 to KDE3 should prove to be relatively painless when KDE 3.0 is released in its final form.