Kernel Cousin KDE #25 For 9�Nov�2001

Editor: Aaron J. Seigo

By Aaron J. Seigo �and� Juergen Appel

Table Of Contents


Welcome to KC KDE! Another week has quickly zipped past and the KDE team has remained hard at work producing a steady stream of CVS commits. The new desktop, which is still officially alpha quality, is becoming quite usable and stabilizing with good cadence.

This week's KC KDE covers several of the development events that occurred this week. We also welcome Juergen Appel to the editing team this week. Juergen will be covering the kde-artist, kde3alpha, kde-edu-devel and kde-worldwide lists. We hope you enjoy the summaries!

1. LDAP KIOSlave

29�Oct�2001�-�1�Nov�2001 (8 posts) Archive Link: "Fwd: [Aegypten] plan: LDAP support via new kioslave!"

Summary By Aaron J. Seigo

Topics: IOSlave, KMail

People: Karl-Heinz Zimmer,�Jan de Visser

An IOSlave for accessing LDAP servers has been a highly requested feature, but until recently noone has had the time or diligence to write one. That is about to change. LDAP integration is one of the requirements in the �egypten project, which is being funded by the German government. After a few weeks of batting the issue around on various lists, the �egypten programmers seem to have come up with a general development plan. Karl-Heinz Zimmer detailed their plans in an email saying:

As you see in our new design plan for LDAP access (see below) we actually managed to find a way how to use the new LDAP kioslave without having to re-implement tons of code for mutt support (which is our 2nd goal and comes right after KMail support).

Now there are several issues where you could help me see things clearer:

As a possible solution to their first challenge Jan de Visser suggested, " Marko Samastur and I came up with something here a while ago. The idea was basically to have the TCPSlaveBase make the TCP socket connection, and pipe the socket through to a unix domain socket. The OpenLDAP client lib has some (underdocumented, but supported) capabilities to use a domain socket instead of a TCP socket. Don't know if Marko got anywhere with that one though..." Karl replied, " this sound very good, by doing so KDE would gain all the benefits from the TCPSlaveBase while still being able to use OpenLDAP. IMHO it would be nice to have this undocumented feature made a documented one - to make sure it will be there in future versions of OpenLDAP as well."

The �egypten people are now working with the OpenLDAP authors to ensure (among other things) that the undocumented features relied upon will remain in future versions. Once complete, this IOSlave could have a deep impact on many KDE applications outside of KMail.

(ed. [Aaron Seigo] To avoid vaporous announcements and raising unwarranted expectations, it is usually the practice of KC KDE to comment on new features only after code has been written. However in this case, since the developers are under contract to complete the functionality and they have generally been making good progress, I thought it would be OK to let this (rather exciting) thread slip in. *knock on wood*)

2. Simplifying the DCOP Process

30�Oct�2001�-�2�Nov�2001 (4 posts) Archive Link: "[PATCH] (Please review) k_dcop_signals patch"

Summary By Aaron J. Seigo

Topics: DCOP

People: Alexander Kellett,�George Staikos

From the Department of Nice Finishing Touches came a yet another DCOP patch, this time from Alexander Kellett who said, " Here's a cleaned up (removed the excluseSelf stuff) patch to add a easier way to call dcop signals. These changes are needed for my first patchs to keditbookmarks so i'd really like to get these in soon as its holding me back from working on the bookmarks stuff." Apparently others have also be waiting for such a patch, such as George Staikos whose first respons was " Oooooooh aaaaaaahhhh :) I've been waiting for this one!! Thanks!"

3. Struggling to Clean Up KConfig

31�Oct�2001�-�3�Nov�2001 (30 posts) Archive Link: "KConfig object-orientification"

Summary By Aaron J. Seigo

Topics: KConfig

People: Charles Samuels,�David Faure,�Dirk Mueller,�Rick Hemsley

Just prior to the KDE3 branch starting there was discussion and general concensus that the KConfig API needed to be tweaked. Charles Samuels started this process and reported, " Well, I've started on the arduous task of making KConfig::group() return a temporary class (KConfigGroup) that has all the accessors (like readEntry, writeEntry, etc). I'm also breaking compatiblity big-time with older versions. As in, major. KConfigGroupSaver is departing, and, well, all sorts of good things. This involves also updating the rest of KDE, and is all very hairy because every single thing in cvs will have to change."

While the changes themselves were seen as a good thing, the method chosen to implement them was not. David Faure commented, "Why can't the code be moved to KConfigGroup, and the old code still be in place, calling KConfigGroup's method with the "current group" (the old notion we're trying to get rid of, but remaining for compat) ?" Dirk Mueller also objected saying, " Then you have to wait till KDE 4.0 if no compatibility layer is there. Besides KConfig is a very performance critical class, so unless you can prove that your changes don't noticeably hurt performance I'm very much against including such a change, no matter how good it is. "

Charles supplied several revisions to the patch in an attempt to improve things, but some of the core developres still had issues with his changes to this very important class. Things then quickly escalated into a tug-of-war as CVS commits were reverted and the discussion devolved briefly into bickering. Eventually calmer heads prevailed and code continued to be written.

Rick Hemsley capped off the event with a thoughtful email that is probably applicable to just about any coding project:

please ask who is maintaining a part of the code so you can discuss changes with them, and _listen_ to them. Also please allow ample time for your patches to be reviewed. Most of us are busy with other things and it can take days to get around to looking at new patches.

if you don't like a commit, please ask whoever made it to revert, before doing it yourself. That way, we don't end up with a tug-of-war, which is quite embarrassing.

I think we also need a MAINTAINERS file, which should be kept up to date, so we all know who's looking after what. Otherwise parts of the code just look like they're semi-abandoned (or 'stable' :) and just being occasionally hacked on/fixed.

4. Disabling Action in XML GUI

1�Nov�2001 (5 posts) Archive Link: "PATCH: defining actions enabled/disabled status in XML"

Summary By Aaron J. Seigo

Topics: XML

People: Guillaume Laurent,�Simon Hausmann

GUIs defined at runtime using XML files are one of the more interesting developments to be seen on modern desktops. Making this functionality as flexible as possible without overdoing it can be tricky, however. Often a good rule of thumb is to implement a solid base design that includes only what is needed and add the bells and whistles as required later. One such feature was added to KDE's XML GUI by Guillaume Laurent who posted a patch and said, " I'd like to commit the attached patch to CVS Head. What it does is allowing the definition of "state changes" in an XML rc file, to make easier the management of actions' enable/disable status. This is done through a new slot in KMainWindow : stateChanged(const QString&);"

After reviewing the patch Simon Hausmann said, " One could generalize this concept to set an actions qt property on a state change. That could be the 'enable' property in most cases, but theoretically any qt property would be possible. Could be a powerful feature. But then again, I can't think of a real use of it for now (other than changing enable/disabled) , so we better not try to solve a non-existant problem" Guillaume replied, " Indeed it could be very useful... I'll do it for the next feature thaw."

5. Registering KDE Mime Types?

2�Nov�2001�-�3�Nov�2001 (4 posts) Archive Link: "registering KDE-specific MIME-Types with IANA?"

Summary By Aaron J. Seigo

Topics: Mime Types

People: Marc Mutz

Now that KDE has matured and is quite widely used, is it time to register its MIME-types with the authorities that be? Marc Mutz thinks so and expressed his opinion saying, " While reading RFC's for KMime I came across the fact that x-* MIME-types are deprecated (rfc2048 - MIME Part 4: Registration procedures). Proprietary mime types should be registered under the vnd. tree. Should we try to collect all KDE-specific mime types under vnd.kde.*?" ... " The big advantage to have our mimetypes in IANA's registry is that they are visible to other implementors. No x-* types are included in the registry (because they're supposed to be reserved for private use)."

Later in the thread, Marc detailed out what registering the MIME-types would entail: " Someone has to fill in the templates in rfc2048 and put it's name on 'em. And it's generally expected that a registration points to a document describing the format. If someone had fun with this, I guess writing an informational rfc for inode/*-type types would be a good idea, too."

Thomas Zander added that if this was done, backwards compatibility would need to be added to various apps to ensure loading of older documents still worked properly.

6. KNotes Joins the PIM Applications

2�Nov�2001�-�4�Nov�2001 (6 posts) Archive Link: "RFC: moving KNotes to kdepim"

Summary By Aaron J. Seigo

Topics: KDE PIM

People: Michael Brade,�Cornelius Schumacher,�David Faure

The whole idea of having separate modules in KDE's CVS repository is to allow similar applications to commingle without having everything lumped into one gigantic and unwieldy tree. This structure occasionally results in applications migrating from one module to another in CVS. Michael Brade wrote, " Rik had the IMHO very good idea to move KNotes to kdepim since it somehow manages personal information and should get better integration with KOrganizer at al. I think this would make the next step for a better KDE PIM suite. If nobody objects it would be great if someone with server access could move the directory on the server."

Cornelius Schumacher, one of the main KDE PIM hackers, provided his support for the move with the single word, "Absolutely." David Faure performed the actual move on the CVS server and commented, " happy to see some integration, but I guess not everyone will be happy to have to install a full-fledged organizer just for a postit on his desktop.... I know, packaging problem, not our problem."

7. Proofreading Strings For KDE3

3�Nov�2001 (4 posts) Archive Link: "[Kde-pim] Fwd: Proofreading message strings: Round 2"

Summary By Aaron J. Seigo

Topics: UI, KDE 3, KDE Usability Project

People: Carsten Pfeiffer

Carsten Pfeiffer wrote, " I'd like to start another round of proofreading of message strings, starting with newly added applications. If any developers want their applications looked at first (especially if it's new or contains a lot of new strings, or just if you're concerned about it) please write and let me know and I'll do them as soon as possible." Even KDE has to mind its P's and Q's, so be sure to take advantage of (or participate in) this effort to give KDE's messages a professional feel.

8. KDE3 Features Plan

5�Nov�2001�-�6�Nov�2001 (17 posts) Archive Link: "CVS HEAD reminder / 3.0 feature plan / time schedule"

Summary By Aaron J. Seigo

Topics: Release Schedule, KDE 3

People: Dirk Mueller

The release schedule continues to grind on and Dirk Mueller, KDE3's release maintainer, continues to chart the path for the project. Dirk posted another of his regular update emails this week, saying:

I've split the 3.0 feature plan in 3 categories now:

I've also removed unclear entries (commented them out). If you are affected, please correct the parts I mentioned in the comment above it and _ask_ _me_ to readd it again. Thanks!

Please keep the entries you added up to date yourself. That means moving them to "status yellow" or "green" as appropiate. If you have a clear timeframe, like "needs 2 weeks", please add this information.

Note: Entries that are still "red" by middle/end of December _might_ be dropped from the feature plan if necessary!

Regarding time schedule:

Some features that had been removed were asked to be added again as the maintainers found time in their schedules. Also, issues regarding BiDi in Konqueror and Xft in Qt 3.0 were raised. The BiDi issues were quickly resolved and Lars Knoll noted that the Xft problems seemed to be licked in Qt 3.0.1.

9. Kalling the [K]Artists

7�Nov�2001 (2 posts) Archive Link: "K-ARTIST:kdeprint needs graphics/icons"

Summary By Juergen Appel

Topics: Icons, Printing, Art

People: Michael Goffioul

On Wednesday Michael Goffioul ( sent in an image ( displaying a beautified version of the kdeprint wizard.

The image ( , which was from a HP driver, cannot be used in KDE because of its copyright. So he asks our artists to draw something similar, including new icons: "If you look closely the kdeprint GUI (manager, print dialog, printer properties), you'll notice some icons are redundant or not suited to the action they represent."

Michael noticed that this was not the first time he called for help so he remarked, " as I already missed the train of the 2.2.x releases, I wouldn't like to miss the 3.0 release." Well said.

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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.