Some months ago Jono Bacon along with a few other KDE hackers started working on a project intended to help guage the usability of KDE. Unfortunately their time became limited and the project stalled for a while. It picked up steam again this week and is once again proceeding with vigor. Jono kicked things off with this email:

Since that email, there has been more activity on the kde-usability list that there was in the previous four months. Many new faces have joined the project and they are busy putting together standardized formats for reports, questionaires, software to help automate the testing process and report drafts. To see the state of the project and join in visit http://usability.kde.org/.

To make sure that there were no questions remaining about the future timeline for KDE Waldo Bastian posted the following summary:

There was a brief discussion regarding whether to move KDE development into a two phase schedule, much like Debian Linux' stable and development branches. It was decided through discussion that this was not the best thing for KDE. As for the "release dude" position, when Waldo announced that KDE 2.2 was tagged and ready to go he also announced that Dirk Mueller will be the cordinator for the KDE 3.0 release.

Waldo's hard work with the 2.x series has been greatly appreciated by all in the KDE community and we look forward to Dirk's release schedule leadership.

QextMDI is a toolkit that implements a multiple document interface (MDI) API for Qt and KDE. Several Qt and KDE applications use this framework. Falk Brettschneider announced a new beta of QextMDI 2.0 was available on its homepage. According to the announcement, the changes in 2.0 include:

There is only one way to know how well a car drives, and that is to actually get in and drive it. Similarly for an API, the only way to really understand its capabilities and limitations is to use it in real world situations. KConfig is one of those ubiquitous parts of the KDE base libraries: any KDE application that needs to store configuration data (which is the majority of them) use it. The strengths and limitations in KConfig have therefore been discovered in detail and the future of KConfig has been discussed several times before. Now that KDE is heading for a new major release in 3.0 it was to be expected that the topic would arise up again. Rob Kaper kicked off the thread by saying:

Simon Hausmann had some concerns with writing out each and every config option, saying:

Martijn Klingens noted that most applications already write out all possible configuration options regardless of whether they are set to the default value or not. XML files were suggested but decided against as requiring too much time and resources to parse efficiently.

On a slight tangent, Charles Samuels suggested:

Several others agreed that this was a good idea and should deffinitely be implemented in this manner.

In the end many questions remained unanswered. It will interesting for both developers and users alike to watch what happens to the configuration infrastructure in KDE 3.0.

Many have been watching Konqueror's tremendous progress towards becoming an excellent web browser. So it's slightly ironic that one of Konqueror's weakness is accurately displaying the progress of downloading and displaying a web page. This is changing however thanks to a patch Dirk Mueller has been working on. Regarding this patch, Dirk said, as I noted earlier I'm currently working on fixing the progress information. What I thought about is putting all the ugly logic that maps the heap of information about the ongoing actions into a 0-100% value in khtmlpart and make it emit a signal that GUI frontends can connect to (void progress(int percent) for example). He went on to ask for input on some of the aproaches he was taking. After a lengthy technical discussion on the finer points of how and when to let the GUI know about various events occuring from within khtml, Dirk posted a patch saying:

Simon Hausman pointed Dirk towards KHTMLPart::parentPart() as a means to find out what the top level frameset is. Tobias Anton tested the patch thoroughly and commented, i like the change in the loader very much! looks like a long-needed cleanup. large, great patch.

Members of the gcc project are working on making runtime linkage more efficient, which is the largest contributor to slow KDE application start up times at the moment. While they work on these solutions other temporary fixes are appearing. One such improvement comes curtesy of Leon Bottou who has released an early version of his objprelink program. When use to process object files prior to final linking, Leon's program can significantly reduce the time it takes to start up an application that relies on external libraries. The first version Leon released had some issues, including only supporting the i386 architecture. This week Leon released a new version saying:

Waldo Bastian even suggested integrating this improvement into the 2.2 build system. Andreas Pour objected to this saying, While I think too this is a great innovation, is it really appropriate to release this w/out a beta test in a stable release? Who knows what different combinations of binutils/linkers/loaders/compilers will do. It might cause rather severe problems, making KDE unusable. Some of these problems could be avoided if there was a "configure" switch labelled "experimental" to enable this, and then the distros can at least verify that it works on their particular systems when building the packages. While it may not make it into 2.2, there is hope that this will be seen 2.2.1 and/or later until actual prelinking is available in commonly used compilers. This is a very important advancement in general as Roberto Teixeira noted, IMHO, this is just a too big improvement to be left aside. The speed gain is considerable and we'd be reducing, if not killing, one of the most common (_the_ most common?) complains about KDE: speed. OTOH, I really think we should not let it be included as default, so I am really in favor of using a configure option, disabled by default.

For those that have watched KDE compile, you will have noticed the -fno-exceptions flag in the compile command and Makefiles. Anatoli Gorchetchnikov asked about this saying, What is it? I'd love to catch couple of exceptions my core library (non-kde/qt) throws and let user handle it through interface of my kde app. What problems can it cause?

This caused a small argument over whether exceptions in C++ were a good thing or a bad thing. Allan Sandfeld Jensen noted some of the caveats saying, The overhead they talk about, is among other things also a lot of code, not dealing with what you wrote, but just dealing with exceptions. Try make a call to new() with and with-out exceptions, in the standard it _might_ cast an exception and gcc inserts code to deal with this. If you dont expect this and is programming low-level binaries or drivers, this is a serious hazard. Whats even more, since how exceptions are implemented are not general, you cant count on any specific behavior. A library shouldnt cast exceptions since this breaks non-exception handling user code, or insert various handlings per default.

Waldo Bastian also put in some sage advice with regard to exceptions and KDE saying, Exception handling causes huge overhead, it caused an overhead of about 1Mb / process for KDE applications when I last measured it (about a year ago). I don't think this has changed much with gcc 3.0. You can use exceptions in your own code though, as long as you don't throw any exceptions through Qt or KDE code. (Watch out for signals/slots) Your application will crash or abort when you attempt to throw a signal through Qt or KDE code (when it is compiled with -fno-exceptions) You have been warned.