Kernel Traffic
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

KDE Traffic #5 For 6�Apr�2001

By Aaron J. Seigo

Table Of Contents


Welcome to KC KDE! This week in KDE development was highlighted by several parts of the KDE framework that are slated for the 2.2 series reaching important milestones. KPrinter, KDE-DB, support for IPv6 and SOCKS, KDevelop and KMail (among others) came to such points in their development this week. Correspondingly, the mailing lists were very active with implementation discussions, announcement and a constant flow of bug fixes and feature enhancements. Enjoy and happy hacking!

1. Access Control Lists Added to CVS For Commit Privileges

26�Mar�2001�-�29�Mar�2001 (15 posts) Archive Link: "ACLs in KDE CVS"

Topics: CVS

People: Kurt Granroth,�Hans Mein,�Waldo Bastian

Kurt Granroth announced to the list a new CVS policy, saying: " I am implementing rudimentary access control lists (ACLs) for the KDE CVS. Certain modules in CVS will have restricted commit policies. That is, only those users explicitely specified will be able to commit to them. The two modules that that are restricted are (currently) CVSROOT and www."

Hans Mein asked, "Why do you think it is neccessary to have more tight access rights to the www module than to kdelibs?" . Kurt in turn explained the reasoning behind the changes in greater detail saying, " If anybody makes a bad change (or worse, a destructive change) to a KDE module, it can be reverted before any harm is done. But that's not true in the case of the www module. The website updates every 30 minutes (or so.. I don't remember anymore). So say somebody wants to make a destructive change to the KDE website (this is all the more possible now that everything is PHP). They could do so and have it distributed worldwide instantly with no peer review. That's the difference between, say, kdelibs and www. *All* changes to kdelibs are "reviewed" before they are releases whereas it's very possible to make changes to www that are released before they are reviewed."

Waldo Bastian also gave some insight into the future direction of ACLs in KDE CVS saying: " we want to move in a direction where people have the access that they need as opposed to the current scheme where everyone has access to everything. If things work out with www then kdelibs is probably the next target. If you want access to www you just need to drop Kurt a mail and he will give it." With a project as large and important as KDE, it is good to see that there is such care and concern being put into the safety of the code base.

2. Directories, Mime-types and Input Filters (Oh My)

27�Mar�2001�-�29�Mar�2001 (16 posts) Archive Link: "Part loading where mimetype won't work and KIO filters."

Topics: Mime Types

People: Rik Hemsley,�Martijn Klingens,�David Faure,�David Sweet,�Alexander Neundorf

While working on the audiocd kioslave, Rik Hemsley ran into an interesting challenge, which he explained in an email saying:

  1. I'd like to have a KPart loaded when audiocd:/ is requested. I can't do this based on mimetype because audiocd:/ has a type of 'directory'. Is there a way to load a part based on URL ? The other tricky part is that the part must not be loaded if a filename is specified, e.g. audiocd:/track01.wav
  2. KIO's filter mechanism seems to be designed specifically for decompression of specific mimetypes. I'd like to compress data, but the codec is selected by the user and obviously I don't want it to be used every time they try to open a WAV file.
Any ideas ?

Martijn Klingens replied, saying, " You might want to read the thread on kde-devel about directory mimetypes ;-) It was suggested to create specialized mimetypes like inode/audiocd-directory that inherits inode/directory. In that case you can load the part based on the mime type .." This seemed to be exactly what Rik was looking for. In the thread Martijn was referring to, David Sweet had asked a question very similar to Rik's regarding mimetypes and directories. David Faure and Alexander Neundorf came to the conclusion that extending the mimetypes for directories through inheritance would work well. It could be done so that nothing broke or had to have special knowledge of the various types of directories while still allowing specialized treatment of those directories were appropriate.

As for point 2 in Rik's email, David Faure said: " That was quite an oversight from me, making the KFilterBase API so tied with the compression stuff. But in fact, this is just playing on words. We can still put together a generic solution for KIO "filters", or any other name we can find so that it's not the same as what's already used by kfilterbase. Let's say I call this "layer", lacking any better name. We could make a base "layer" class, and associate layers to mimetypes, add some configuration for whether to use a given layer automatically or not, etc. The compression stuff (KFilterBase/KFilterDev) is only one case of layer - the one between compressed data and uncompressed data. In fact if you agree that QIODevice is a nice API for such things, then that's our base class. KIO could plug any QIODevice on top of data read from the network-transparency stuff (including kio_file), allowing any kind of conversion on top of that. That's why KFilterDev is a QIODevice too. Would the wav<->audio stuff fit in a QIODevice ?" Both Rik and Alexander agreed that this would be a good and workable solution which could end up allowing seamless and transparent transitions from one data type to another based on context. Rik explored the possible implications this could have, saying, " Say you have a layer that converts text/x-man to text/plain and one from text-man to text/html, konqy would pick text/html because it gives the most useful rendering. We would also need a list of default priorities to let konqy make the 'best' choice when possible. This would be an extension to the filetype mechanism, which currently allows setting priority order and specifying whether embedding is desired."

3. KDE 2.2beta1 Round Up

27�Mar�2001�-�29�Mar�2001 (21 posts) Archive Link: "KDE 2.2beta1"

Topics: Release Schedule, KDE 2.2

People: Waldo Bastian,�Sergio Moretti,�Frerich Raabe,�Joseph Wenninger,�Guillaume Laurent,�Stephan Kulow,�Michael Goffioul

Waldo Bastian, keeper of the release, put out a call for progress reports saying: " KDE 2.2beta1 is planned for next week but several people warned that they are still midway some changes that they would like to complete before the first beta. So in order to make a decision about KDE 2.2beta1 I would like to hear from you if you are working on something that is currently not ready yet to be released. I would also like to know when you expect it to be ready (1 day, 1 week, 1 month, 3 months....)"

Michael Goffioul reported that the KPrinter framework had achieved functionality on par with what was in Qt and was ready for use, though more work was left to do. Stephan Kulow noted that the documentation system rewrite that was underway was going to be another month before being in reasonable shape. Guillaume Laurent noted that scoring and other goodies from the new kdenetwork library would be in KMail within the next two weeks and Frerich Raabe noted that KNewsTicker would be ready in a similar time frame. Mosfet said that Pixie was ready and that he was releasing another development release imminently. Joseph Wenninger noted he had Kant/Kwrite work to finish up by the first week of April. Sergio Moretti posted his work on the KIO architecture which is aimed at introducing a slave/slaveManager relationship. Sangohn Christian noted that he would have a parallel printer configuration module for KControl ready in approximately two weeks. Waldo added to this list the new KDE-ICE, IPv6 support, KMail IMAP and the usual wide array of bug fixes throughout the code base. It looks like 2.2 is going to be an exciting upgrade indeed!

4. KDE Database Connectivity

27�Mar�2001�-�28�Mar�2001 (5 posts) Archive Link: "KDE-DB enabled in CVS"

People: Alessandro Praduroux,�Mike Richardson,�Henrik Johnson,�Dan Williams,�David Faure

Alessandro Praduroux who has been working on the KDE database connectivity module as part of his work at theKompany made an timely announcement to the list saying:

I've just enabled the compilation of KDE-DB in kdelibs CVS. I've updated it to make BC-aware, and it actually works AFAIK ;).

The MySQL plugin is the most complete, but also the Postgres one works. Other plugins are more than welcome.

Some code using KDE-DB is scattered across KDE CVS:

I'm open to any question and bug report ;)

Mike Richardson, who also had done some database/KDE work in concert with theKompany said, " I have a partially working plugin for XBase files. This needs two extra libraries, libxbase ( and xbsql (" He wasn't the only one looking to add to the list of plugins for kdedb. Elsewhere Henrik Johnson piped up saying, " Is there any interest in having Oracle support for kdedb, I've had a look at this and think I can whip something together." In response to this Dan Williams said, " I was just starting to look at doing a DB/2 module myself. I have it installed on my system. I agree that having support for DB/2 & Oracle would be a big plus."

At this point David Faure stepped in with some pragmatic questions about the future of kdedb, saying: "Qt 3 is arriving with DB support. On the other hand, we have kdedb now, but the author (Alessandro), and theKompany in general, seem to indicate that they don't intend to maintain it in the future. In the light of this... is it really wise to keep kdedb at all ? If the need for DB support is urgent, then of course "what we have now" is better than "whatever will come in the future" (from Qt). But OTOH if this can wait a little bit, we can perhaps drop kdedb completely and go for Qt3's DB support, which is guaranteed to be maintained." Alessandro was quick to reply saying that he was indeed planning on maintaining kdedb in the future. Henrik evaluated the new Qt database code and gave his take on the situation saying, " it seems like the Qt DB interface is a subset of KDE DB. You have no builtin functionality to browse databases and/or modify/create database objects in Qt SQL. The way I see it the KDE DB would fit nicely as a superset of Qt SQL which add this functionality from the basic prepare/execute/fetch framework that seems to be provided by Qt SQL." Reginald Stadlbauer of Troll Tech pointed out that you could indeed do all of this from within QtSQL. However, Henrik pointed out that it was not done in a database neutral manner and this is exactly what kdedb would allow.

5. Kaboodle: An Embedded Media Player

28�Mar�2001�-�31�Mar�2001 (12 posts) Archive Link: "Fwd: Kaboodle"

Topics: Multimedia

People: Neil Stevens,�Stephan Kulow

Neil Stevens of KDE Multimedia fame wrote, " Could someone with the appropriate server access move Kaboodle from kdenonbeta to kdemultimedia? So you don't have to ask: Kaboodle is a lightweight media player made into a KPart. It doesn't fill the same role as Noatun. Kaboodle is meant for playing or previewing individual media files conveniently."

This caused Stephan Kulow to say: " I don't see the reason why we should have a media player and a lightweight media player. And I fail to understand what 'playing conveniently' means here. I haven't seen kaboodle yet, but I don't think I want another media player." In response, Neil wrote a long email with a careful explanation of why Kaboodle was a necessity in his mind, saying:

The relationship between Noatun and Kaboodle is much like that between KWord and KWrite, or Pixie and KView. Superficially they seem to do the same thing, but the two apps are designed to be used in different ways.

Noatun is a good music player: It's set up to have you load all your files in a playlist, turn on some effects or not, and just let it run all the time. Noatun works really well in one's session, because once you load a playlist, you don't ever have to load it again. It can just run and run and run.

If I run noatun as a music player, and have my hand-tuned playlist all set, I won't want to use noatun for clicking on files in KMail or Konqueror. It'll mess up my playlist. That's a tradeoff.

Someone who only uses media files in one way may not need both Noatun and Kaboodle. One or the other will suffice. But playing background music is a task quite different viewing a movie. mpeglib might not be ready for this until after KDE 2.2, but eventually Kaboodle is going to be able to play videos just like aKtion does - with the video embedded.

OK, that's one argument, and that was my primary motivation for writing Kaboodle. However, several other advantages have fallen out. First, it became obvious that making a KPart plugin out of Kaboodle would be very useful. Nikolas did it, and it seems to me he did a good job of it.

Second, I've had people tell me that while Noatun (and arts) uses more cpu time than they would like, Kaboodle's cpu use is "like xmms." I think this is because of all the aRts infrastructure that Noatun sets up, in order for the effects, visualizers, and volume control to be possible. If the difference between Noatun's and Kaboodle's cpu load while playing is that big a deal to people on low-end machines, it seems to me that it can only be beneficial to include both.

After further discussion it became apparent that Kaboodle was the only solution available in KDE in this niche for the forseeable future. It has yet to be moved into kdemultimedia from kdenonbeta in CVS.

6. KPrinter Support Added Across KDE2

29�Mar�2001�-�30�Mar�2001 (6 posts) Archive Link: "KPrinter"

Topics: Printing

People: Nikolas Zimmermann,�Nikolas Zimmerman

After much work all across the KDE code base, Nikolas Zimmermann announced the fruits of his labors saying, " I converted all packages kdebase, admin, network.... except of bindings + nonbeta to KPrinter. Ready :)" Concerns were raised over how new and relatively untested the KPrinter framework was. Nikolas laid these worries to rest saying, " i tested LPD and extensive tested CUPS both no problems! _GREAT_ work :)" Of course, this is exactly what the KPrinter system was written for and the only way to see it mature is to put it into use. After all, thats what CVS is there for.

7. Kant Renamed To Kate

29�Mar�2001�-�31�Mar�2001 (54 posts) Archive Link: "Any new name suggestions for Kant ?"

Topics: Kate

People: Cullman Cristoph

Cullman Cristoph sparked what might be one of the bigger branding uproars since New Coke when he opened up the floor for name suggestions for Kant saying: "at and in many mails people want a rename of kant to something more intuitive ... Therefor I want to get some suggestions of a new name for Kant. Any ideas, comments, ... ?"

Since Kant is successor to the venerable KWrite and has already gathered much attention over its design this captured a lot of attention and discussion. In all, nearly 40 different names were proposed for consideration. These included such entries as Kute (KDE Universal Text Editor), KickEdit, KWordPad, KAuthor, KWritePro, Kontext and Ked. In the end the new name that was settled upon was Kate, an acronym for KDE Advanced Text Editor.

8. Gideon: KDevelop's New Development Branch

30�Mar�2001�-�3�Apr�2001 (14 posts) Archive Link: "A new IDE for a new milleneum :-)"

Topics: KDevelop, Gideon

People: Bernd Gehrmann,�Kurt Granroth,�Cullman Cristoph

KDevelop has been long hailed as one of the premiere open source IDEs. The KDevelop project has had some tense moments durig the KDE1 to KDE2 transition and only recently has there been a version released that allows KDevelop to compile using KDE2 libraries. This was only a stop-gap measure, however, as the KDevelop team worked on the next major step in the IDE's evolution code named "Gideon". This week saw Gideon moved into KDE2 CVS head which was accompanied by the following announcement on the list by Bernd Gehrmann:

Ok, let's start with a bit of history: In late summer 1999, we branched kdevelop in order to port it to KDE 2. At the KDE Two, Sandy and me began adding new features to it while the old branch was bugfixed for the 1.0 release. In the following months, not very much happened, with the con- sequence that last summer we had a HEAD branch that was quite buggy (because bugfixes were commited only to the 1.x branch) but had some features more (except for the debugger).

Then came the big cut. The HEAD branch became a vision of an IDE that would solve all the problems one could imagine (including world hunger and pollution). Unfortunately, such visions have a big problem: It needs a lot of time and patience to realize them. In the world of free software, the situation is even worse: as long as there's a branch of a program that works (even if it doesn't work very well), there's little reward in working on a branch that crashes on the first startup, lacks essential functionality and doesn't look like it gets completed any time. Sometime in january of this year, it was very clear that the HEAD was dead, just that everyone was too much of a coward to openly admit it.

Since I thought it would be a pity to completely abandon the very nice code in HEAD, I decided to bring it into a state that it could compete with the 1.x branch both in terms of stability and features. Only that can motivate people to finally bury the old stuff. The only possible way I saw was to turn the whole code upside down, remove everything that couldn't be completed in a finite time, remove stuff that was too ambitious or that I don't understand and replace it with something that works. And of course, for my own motivation, I added lots of useful, fancy and neat features :-) I'm fully aware that some people will be pissed by me removing their code, and I'm very sorry about that (and in particular I would really like to see Sandy's work on the application wizard merged back), but I don't think it was avoidable.

So what do I have now? First, a modular lego-like framework for an IDE that could be used to build a C++ IDE, a Python IDE, or even a web development platform (no, I'm not suggesting the latter ;-) In the second place, a number of 'part's that make use of the framework and form a complete C++ IDE. That is:

Anything I forgot? :-) Well, most importantly, most of the code is modular, extensible, clearly written and maintainable.

Bernd went on to expound on the current abilities (and shortcomings) of each of the parts of Gideon. He also pointed to screenhshots and even a tarball of Gideon in its current state (

There was a general sense of approval on the list and appreciation of all the work that has gone into this project. Kurt Granroth asked if it was going to be possible to interchange the text editor using a generic KPart editor in upcoming releases. Cullman Cristoph, the Kant/Kate maintainer, agreed that this would be a better long term solution. Bernd noted that the choice to not make this aspect of Gideon a KPart was a pragmatic one due to needing something to release sooner rather than later. He also stated that using a generic editor part made the most sense in the mid- to long-term and would eventually be implemented.

9. Another Programmer's Editor Debuts

30�Mar�2001 (6 posts) Archive Link: "Programmer's editor"

Topics: New Application

People: Roberto Alsina

It seems the world can never have enough programmer's editors. Roberto Alsina announced KDE/Qt support was now available in FTE saying, " To anyone wanting a nice, quick, damn fast and featureful programmer's editor that runs on almost anything, check out This baby has frontends for DOS, OS/2, linux console, vtxxx terminals, plain X, Qt and windows. It has way more features than I can name here, but the main one: I need a few testers ;-) If you have used kfte from CVS, this is the same editor, only it now works much better :-)"

10. To QuickPrint or Not To QuickPrint...

31�Mar�2001�-�1�Apr�2001 (13 posts) Archive Link: "QuickPrint implementation (RFC)"

Topics: KDE Usability Project, UI, Printing

People: Michael Goffioul,�David Faure,�Waldo Bastian,�Ferdinand Gassauer

Michael Goffioul asked, " Somebody pointed me out that it could be very useful to have some kind of quickprint button because most users won't need the complete print dialog everytime. So I thought a little bit about it, and here are some considerations about the implementation I have so far. I'd like to have external opinions...From a visual point of view, it would look like a tool button with a delayed popup menu. Simple click would print on the printer whose name corresponds to the "name" of the button (here "name" is of course not the QObject name, but something else). Maintaining the button pressed would show a popup menu with available printers. Any suggestions ? Would this be useful ?"

David Faure noted that Michael's planned implementation looked good but then added: "OTOH from the user point of view, I personnally hate such buttons. I often click on the wrong button by mistake, and since it starts printing immediately it's too late already. IMHO there should at least be a confirmation dialog box [maybe with a don't-show-again], or the full dialog with everything already set up... which is the case by default, isn't it ? :}" Michael agreed with David on this point, but added that if the user base wants it, they should be catered to. David replied that he thought it would merely be copying a "Microsoft Mistake". Ferdinand Gassauer and Waldo Bastian both agreed with this viewpoint and Michael decided that perhaps quick printing wasn't a good idea.

11. Improved Sending in KMail

31�Mar�2001�-�2�Apr�2001 (4 posts) Archive Link: "PATCH: Non-blocking sending"

Topics: KMail, KIO

People: Don Sanders,�Neil Stevens,�George Staikos

One of the more outstanding issues remaining in KMail is the graceful handling of large messages. A step towards improving large message support is non-blocking sending, something that Don Sanders has been working on. He announced inclusion of his non-blocking patch on the list say, " Here is an updated non-blocking sending patch. If I don't find any problems soon I plan to commit it to cvs (at long last)." Outside of a few timing problems the patch seems to be successful and was committed to CVS.

On a related note, Neil Stevens asked: " Is there anyone currently working on getting kmail to use kio_smtp for KDE 2.2? I want to work on it, alone if I have to, because I cannot send my mails with KMail until it's in." Don asked what the benefits of this would be, to which Neil cited SMTP auth while George Staikos pointed out that it would enable IPv6 and SOCKS support. IMAP and POP support already use their respective KIO slaves. Neil eventually posted a patch to include kio_smtp for review to the KMail development list.

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.