KDE Traffic #19 For 3�Aug�2001

By Aaron J. Seigo

Table Of Contents

Introduction

Welcome to KC KDE! This week's issue comes in spite of downed email servers, ISP's giving up the ghost and all sorts of general network troubles that made me start to think that I was living in the middle of some cosmic conspiracy to deny my systems access to the Internet.

On a brighter note, KDE 2.2 is ready to go and the road towards KDE 3.0 is already being forged. Binary compatibility in the libraries is set to be broken to allow needed improvements while others are breaking KDE speed barriers. These events and more are covered in this issue. Enjoy and happy hacking!

1. KDE Usability Project Back On Its Feet

23�Jul�2001�-�26�Jul�2001 (11 posts) Archive Link: "Getting the ball rolling"

Topics: KDE Usability Project

People: Jono Bacon

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:

From some discussion it is clear we need some form of usability testing. This will not only give our product a sheen but also identify areas of user preference in what users want.

What I need to know is who can help and what they do? IF anyone can help witht he following it would be great:

If you could outline which areas you can help in that would be great.

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/.

2. The Road Ahead Includes a New Release Manager

23�Jul�2001�-�27�Jul�2001 (19 posts) Archive Link: "RFC: The Road Ahead"

Topics: Release Schedule, KDE 2.2, KDE 3

People: Waldo Bastian,�Dirk Mueller

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

To wrap up the Qt3 discussion and to bring everyones expectations a bit in line, here is a proposed time-table for the rest of this year:

I suggest to switch KDE CVS to Qt3 after the release of 2.2.1.

If you would like to be the release dude for KDE 3.0, now is a good time to step forward :-)

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.

3. New Version of QextMDI

25�Jul�2001�-�26�Jul�2001 (7 posts) Archive Link: "QextMDI --> kdelibs ? [was: Re: ANNOUNCE: QextMDI-2.0.0 Beta1 out now]"

People: Falk Brettschneider

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 (http://www.geocities.com/gigafalk/qextmdi.htm) . According to the announcement, the changes in 2.0 include:

4. Possible Directions For KConfig in KDE 30

25�Jul�2001�-�26�Jul�2001 (36 posts) Archive Link: "RFC: KConfig changes for 3.0"

Topics: KConfig, Development Plans, XML

People: Rob Kaper,�Simon Hausmann,�Charles Samuels,�Martijn Klingens

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:

Please give some input on the following idea. For KConfig in 3.0 I would like to see the following changes:

That way, users can be assured there are no "hidden" options in the code ever. Every configurable option will be in the configuration file.

My concerns regarding this come forth from the removal of "Fade out applet handles" from kcmkicker. Since it has no GUI entry and is not present in the default saved configuration file, there is no way to know whether the option exists but to be familiar with the code.

Proposed changes would also make it fairly easy to add "Advanced options.." buttons to KControl as that could be a small program reading all the entries, defaults and descriptions. Launching Kate with the appropriate rc file and a special highlight mode would probably suffice.

Another option would be to switch to XML based configuration files, which allows us to store possible values in a DTD and have a generic "RC Editor" (or a Kate plugin) for advanced features. Such a config file editor would probably be the best option to keep KControl simple yet allow power users to tweak all advanced features of a program.

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

There's one disadvantage with always writing out configuration values: They get written into the local config and if you do that for each and every entry you

  1. get full blown config files in the user directory, containing redundant information
  2. loose the ability for a system administrator to change global values, because the global changes never get applied to the apps as for each field there is an entry in the local file.
What we actually need for a kconfig editor is the meta information of which field having which type and some documentation around it (that's an argument for not putting the description in the kconfig file -> you might want to translate the description) . Maybe we shouldn't try to put this information into the config files but into a separate file/database.

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:

we should eliminate the obvious lack of OO safety in KConfig and always explicitly set a group when accessing a key. My personal favorite way is a group(QString) function that returns a temporary KConfigGroup. In other words

config->group("Some Group Name")->readEntry("Some Key");

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.

5. Konqueror Showing Progress

26�Jul�2001�-�28�Jul�2001 (5 posts) Archive Link: "progress patch"

Topics: Konqueror

People: Dirk Mueller,�Tobias Anton

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:

this is a prelimiary version of working progress information. It has a few defiencies currently (one of them is that it is not well tested). Namely there are:

Besides that, the patch has also some other minor fixes and changes, as

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."

6. An Option For The Speed Obsessed

27�Jul�2001 (24 posts) Archive Link: "Faster startups by fixing C++ object files before linking (new version and results)"

Topics: Building KDE, Performance

People: Leon Bottou,�Andreas Pour,�Roberto Teixeira,�Waldo Bastian

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:

My machine is now running objprelinked qt, kdelibs and kdebase. On kdelibs, the number of R_386_32 went from 54216 to 15085. It feels noticeable faster. But I would like much faster than that :-). Some day I should try again with lazy binding.

Attached is a new version of objprelink with a larger message buffer (some symbols have more than 256 chars) and a beginning of multi-architecture support. I hope some people will be interested enough to write the stubs for their preferred cpus.

I am just proposing a simple solution that can work now. If you build QT and KDE with objprelink, you should feel a speedup regardless of the other components of your system. It works now.

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."

7. Objections to Exceptions

30�Jul�2001�-�31�Jul�2001 (15 posts) Archive Link: "reason behind fno-exceptions?"

Topics: Building KDE

People: Anatoli Gorchetchnikov,�Allan Sandfeld Jensen,�Waldo Bastian

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.

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.