Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Kernel Cousin KDE #7 For 20 Apr 2001

By Aaron J. Seigo

Table Of Contents


Welcome to KC KDE where we once again attempt to cover the vast amount of weekly traffic on the KDE mailing lists. Development efforts were strong this week following the release of KDE2.2alpha1. Much work went into bug fixing and refactoring for efficiency this week, but new features and frameworks were also a highlight this week. The goodies this week in CVS included a new IceWM theme importer, further work on both the game and network libraries, a new and (much) improved News Ticker applet and the usual leaps and bounds that we have almost come to expect in Konqueror, Kate and others. Below are some of this week's email list highlights. Enjoy and Happy Hacking!

1. PGP Support in libkdenetwork

8 Apr 2001 - 17 Apr 2001 (7 posts) Archive Link: "sharing the PGP code"

Topics: Security

People: Mathias Waack

Mathias Waack announced his work on adding PGP functionality to the KDE network library saying, " I've made a first attempt to move the pgp code into libkdenetwork. It works at least for me, but is a bit dirty because of the busy pointer stuff. Kpgp is now a abstract class, each application using it must create its own implementation." A technical discussion of the implementation ensued. It is nice to see more and more common functionalities being abstracted out to the libraries where the work can be leveraged by other KDE applications as well.

2. Scoring of Messages In KMail

8 Apr 2001 - 13 Apr 2001 (18 posts) Archive Link: "PATCH : scoring"

Topics: KMail, Performance

People: Guillaume LaurentMichael Hackel

Guillaume Laurent added support to KMail for scoring of messages, using the new scoring code in libkdenetwork that was ported from KNode. After forgetting to actually attach the patch to his email several times, he finally managed to get it to the list saying, "This patch is to add message scoring to kmail. If everybody is fine with it, I'll commit it."

Michael Hackel noted a few problems with the patch, saying:

first of all switching folders is already slow enough. With your patch switching to a big folder is again slower by a factor of 8 (!) even for people that don't have any scoring rules defined. I consider that far from being acceptable.

Then at least I personally thing, that I don't need this feature, therefore it would be good, if there would be a possibility to get rid of that "Score" column if a user isn't interested in that feature. Maybe only displaying it if a scoring rule for the selected folder is defined would be a good idea.

Regarding the position in the configure dialog I think it would also fit a tab on the Appearance page. Some other aplications have fairly small icons for the pages and sometimes even a tree structure in them. However KMail has very few very big icons there and therefore several tabs on the individial pages. I think we should stick to the present pages if at all possible.

Finally I din't manage to get any score displayed in the Score column. I don't know if I need insctructions for that of if it really doesn't work.

At least the message box action seems to work. However first one of the values I entered was not remembered which caused the rule to match every message. After answering 10 of probably 2000 dialogs to come I decided to kill KMail. I think there should be at least a "Ok to all" button.

Over the course of the next several days all the issues were worked out in a thread on the kmail list that consisted primarilly of Guillaume posting solutions and Michael either verifying the fix or sending Guillaume back to the drawing board.

3. Moving System Info Out Of KControl?

9 Apr 2001 - 14 Apr 2001 (9 posts) Archive Link: "Proposal: Moving the "Information" module from the control panel"

Topics: KControl

People: Dawit AlemayehuCullmann CristophAlex ZepedaMalte Starostik

Hardly a week goes by without someone proposing restructuring the KDE Control Center in some way. This week was not the exception, as Dawit Alemayehu made a proposal saying: "I wanted to float the idea of moving out the whole information section in the control panel into its own dialog box that I discussed on IRC with David. The reasoin I suggested this was that IMHO the control panel is usually associated with a place where one makes modifications and changes to affect/control behavior of desktop and related application. Though the information tab might provide information necessary in accomplishing that under some circumstances, it is not an essential aspect to make such changes.My idea hence is to move the information module into its own application, something like ksysinfo and place it under Utilities (K->Utilities->System Information). This can then be used to relay as much information about the system as desired."

Cullmann Cristoph voiced his disagreement with this saying, " the control center should be the CENTRAL place in kde for all system settings/info/managment ! (in my eyes). The users love windows 2000 managment console (or better: the most people using 2000 and really working with their system likes it). KDE should have such a central place too (and control center is allready such a place). Therefor I don'T like the idea of removing the information stuff (but nothing against a redesign or a more useful implementation (like some settings for X instead of only a information). " Richard Boss agreed with Cullmann, pointing out that if system information was moved outside of KControl then it would be harder to find.

Alex Zepeda pointed out another challenge to the system information modules in control saying, "The big problem is that ksysctrl is VERY ia32 centric, as well as Linux centric, and as such IMO should be in the kdelinux module or somesuch. OTOH the kcminfo modules are abstracted reasonably well, altho they could stand to be reorganized a bit." Alex also mentioned that he thought that the KControl area as the proper place for such things.

Regarding such a restructuring, Malte Starostik said, "I do like the integrate-it-into-ksysctrl idea though. IMHO ksysctrl is a little extreme in how it clones Win9x's device manager but with all the controls that might change settings disabled (or is that a planned feature?). Anyway, I think some kind of compromise between ksysctrl's compact structure and the info the other modules provide would be nice. I do volunteer in principal, but I fear I don't have enough time to do that all."

The general consensus in this and other threads seems to be that KControl is usable but not great. Expect to see continued KControl movement.

4. Which socket implementation to use?

11 Apr 2001 - 13 Apr 2001 (9 posts) Archive Link: "[Kde-games-devel] Client-Master"

Topics: Sockets, KDE-Games

People: Andreas BeckermannGeorge StaikosBurkhard Lehner

Andreas Beckermann has been working on implementing a common network layer for KDE Games. He posted to the list announcing that a new version of this work was available in CVS. In the announcement he also asked: " Burkhard: Do you still want to port libkdegames to QSocket instead of KSocket? If so then KGameClientSocket is the place for you :-)"

George Staikos pointed out that if one uses QSocket instead of KSocket you lose IPv6 and SOCKS support. Burkhard Lehner posted a long and detailed message outlining what he saw to be the strengths and weaknesses of each, concluding that QSocket was probably a better choice for what he was doing. He also tried to locate "KExtendedSocket" since it appeared in the documentation he had and seemed to fit the bill fairly well. However, no matter how hard he looked in the source tree, he couldn't locate it. George Staikos pointed him in the right direction saying, " If you use KSocket from CVS, you're using KExtendedSocket. :) Talk to Thiago if you need more functionality and don't know where to go with it. You really should be using the code in libkdecore though. It' contains a lot of the platform independed and kde-uniformity that should be in all applications." Armed with this information, Burkhard posted the following game plan:

change the code in KGameClient and KGameConnectionServer for using QSocket. And I write a small wrapper class (e.g. "KBufferedSocket"), that is a subclass of QSocket but uses KExtendedSocket for connecting. This wrapper class could be easily replaced again with QSocket when QSocket supports everything we like. Or, if this will not happen (what I don't expect), it could be made a part of kdecore and replace KSocket in the near future, since it is much easier to use.

Any other suggestions or comments? I will start my work over the easter days, and if it compiles okay, I will commit it. (Others will have to test it, since I haven't the chance to test it on a real network, and connections on localhost are boring :-))

5. Extending the KDE Address Book

12 Apr 2001 - 17 Apr 2001 (17 posts) Archive Link: "kab and Aethera and Kapital"

Topics: KAddressbook

People: Shawn GordonRik Hemsley

Shawn Gordon started a thread on upgrading the KDE Address Book, or KAB, saying, " We've gotten a lot of requests to share a single address book between Aethera and Kapital and that we also make use of kab as that repository. This makes a lot of sense, but on a cursory examination of kab, it doesn't have near enough information to support the Kapital address book. Now before we just jump in and start changing it to suite our needs, I would like to see what the situation is with kab and if what we are talking about would be viewed as a good or bad thing. Thanks!"

Rik Hemsley replied to this saying, " Sounds like a good thing to me... I've written large parts of an implementation of my idea for a kab replacement, which supports multiple addressbooks, per-addressbook user-defined formats and pluggable storage backends. There's only one backend in existance at the moment, 'file' - which is concurrent-access and NFS safe and seems to work well. An LDAP backend would be easy. Next I need to think about the design of the searching interface and decide whether I should be interfacing with kdedb or Qt 3's DB stuff for a DB backend. Perhaps we could discuss whether the approach I have taken will be suited to the needs of Aethera, Kapital, etc., and if not, how I should proceed ? " Rik and Shawn arranged a meeting time on IRC to discuss the issue and come up with a plan. It should be interesting to see what will come out of this.

6. Widget Style Coding Tutorial

14 Apr 2001 (4 posts) Archive Link: "Tutorial for widget style development, programmers only."

Topics: HowTo, Look and Feel

People: Rik Hemsley

Rik Hemsley, spurred on by the general lack of documentation on the matter and the IBM-sponsered theming competition, wrote a tutorial on how to code new KDE widget styles. He announced the availability of the tutorial saying:
Tutorial on writing your own KDE widget style from scratch. Includes a full working example and an easy-to-use empty framework you can use to start from.

This tutorial should be part of the dot tutorial series, but dot is down right now and there's not long until the IBM competition closes, so you can have it now.

The tutorial text isn't very large, mostly because it doesn't need to be. If you have written Qt code before, you won't find writing a style difficult. There are plenty of tips there, though, to help you on your way.

The example style and the skeleton should be the most helpful bits.

7. Using Mozilla's Gecko in Konqueror

15 Apr 2001 (6 posts) Archive Link: "mozilla integration"

Topics: Konqueror, KDE Bindings

People: Lev PovalahevNikolas Zimmermann

Lev Povalahev asked the KDE2 developers: " is there any way to use gecko for HTML rendering in Konqueror? " This question is asked fairly often by the users of KDE2. Nikolas Zimmermann provided the answer, saying:

you need to use "KMOZILLA" you'll get this new renderer if you do:

I am pretty shure, i forgot one thing, if done this one time some months ago...but do you really wanna use that ? :)

8. Qt from KDE CVS or TrollTech?

16 Apr 2001 (4 posts) Archive Link: "qt-copy or qt-2.3.0?"

Topics: Qt

People: Dennis PowellDaniel Molkentin

Since there is a qt-copy in the KDE cvs tree, many newer developers and KDE CVS users wonder wether to use that version of Qt or the version they get from Trolltech. Dennis Powell asked this question on the development list saying, " f one were doing a clean build of the head branch, which would be preferable -- qt-2.3.0 as released by the trolls, or the current qt-copy? i noticed that there *do* seem to be some differences. if one is preferred, is it required?" Daniel Molkentin answered saying, "KDE CVS can be compiled with either Qt 2.2.4 or Qt 2.3. The latter enables KDE to use antialiased fonts. qt-copy is Qt 2.3 + some changes backported from Trolltechs internal CVS. I personally use qt-copy and it works just fine. So: Required: 2.2.4 Preferred: 2.3 or qt-copy" Lars Knoll also pointed out that Trolltech's Qt and the version in qt-copy are binary compatible with each other.







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.