KDE Traffic, Part 1 #65 For 29 Sep 2003

By Russell Miller

Table Of Contents


Hi, it's late again, I had a lot of work to do, etc. My priorities have been a little screwed up, and I'm trying to make that right. It's not easy.

I'll have a little treat towards the end for all you electronics-philes. And maybe if I manage to get something done with that microwave power transformer I just salvaged, I'll have a little treat for my enemies too.

This is a two parter, as there are 30 threads to cover. The next part will be up very shortly.

Anyway, on with the show..


This traffic is on a different server. I want to explain my reasons for moving it. I have tried to send this on to Zack all last week, the email has been deferred and rejected. I know of no other way to contact him, and meanwhile, the traffic has not been published.

Obviously, I hold no ill will towards Zack Brown, and I will continue to send these on to him to publish as he sees fit. I am not trying to usurp his role, and I greatly appreciate the service that he has provided and is continuing to provide. Once I manage to regain contact with him, I'll reevaluate whether this method of putting it up is needed anymore. I just think this must go out, and I have no way to contact him.

Note from Zack: I've been having trouble receiving email lately, but hopefully we've at least found a way for Russell to know when an issue has failed to reach me, so he can send it again. I'm still trying to root out the problem. Very sorry for the delays.

Mailing List Stats For This Week

We looked at 1683 posts in 7685K.

There were 378 different contributors. 204 posted more than once. 142 posted last week too.

The top posters of the week were:

1. KDE 3.1.4

5 Sep 2003 - 6 Sep 2003 (5 posts) Subject: "KDE 3.1.4"

People: Dirk MuellerGeorge Staikos

Dirk Mueller said:

just to give you a heads-up: As there are some issues pending I'm currently preparing a KDE 3.1.4 release (which also builds against Qt 3.2, for which a great demand from the packager side exists). If you have anything to backport or know about any showstopper, please let me know.

George Staikos said he had some bugfixes to backport, and also floated the idea of making 3.1.4 the last non-critical 3.1.x update. Dirk kind of agreed, but said that the backporting work shouldn't stop, because some distributors sync to the stable code branch.


2. 3.2 Release Schedule

15 Sep 2003 - 23 Sep 2003 (38 posts) Archive Link: "little reminder on the 3.2 release schedule"

People: Stephan KulowDon Sanders

Stephan Kulow enlightened us by saying (and it's somewhat outdated now, but I'm still going to report it)

I'd like to remind everyone that's 14 days til beta1 is prepared. So everyone having todo and inprogress features in the feature plan: please get your code in shape for beta1. After september I would like to have only bug fixes commited. Especially features that need testing, are very important to have in CVS before 29th.

With Beta1 it should be possible to document and translate for final 3.2. Looking through the feature list, I find some features that do not even have people assoziated, that are todo and sound like a lot of work. Please review the list if you've added items and either set them to done if they are done already (I only have a rough overview what can be considered done and what not) or move them to 3.3 so they disappear out of my view.

Of course you're still free to add items that were done before, it's more than useful for our PR if the feature list is as complete as possible. If you have doubts about features to add, feel free to ask - different people have different views on what's a feature and what's an overdue usability fix :)

Several people said that this just won't do, as they've been counting on a later date that was already promised. Stephan replied, colorfully, "Hmm, you know how to get a release dude by his balls, right?" (and the funny thing is, that quote's not even out of context ;)) And went on to say that he wants to hear dates, that November 9th is way too late for a Beta if they want to have it done before Christmas. Don Sanders replied (and boy, did he reply):

If there are outstanding crashes or even just normal bugs due to KMail features I've implemented then I would like to know exactly what they are. Especially bugs in features I've implemented since the last release. Bug numbers would be nice.

I'm aware of one unreported bug with spell checking where sometimes words aren't highlighted as being spelt incorrectly. Also there's the spelling language selection issue but Ingo has taken responsibility for implementing that. And now I think of it an unreported crash with Ad hoc fitlers I have a fix for that as part of my ongoing client side imap filtering work.

I would have preferred fixing this spell checking problem before moving on to implementing new features. The problem is in kspell in kdelibs and it's proving difficult to fix, I'm currently stuck on that one but I haven't given up on it.

Otherwise IIRC it's been over 6 months since I implemented any new features, and I think within that time most bugs, at least serious bugs in my work should have been found and reported.

I did just fix a serious problem with searching, but that was due to a regression introduced recently. Due to the open nature of KDE cvs that's not really avoidable. system or kroupware code then sorry I don't feel responsible for those areas. Also I prefer to work on serious bugs, and if no one else claims them (like the searching regression) new bugs.

Now crashes in general, and specifically IMAP related crashes are an example of what I consider to be an example of a serious bug. Currently rather than than trying to fix IMAP crashes I'm relying on others to do that. I'm betting on them being able to fix those bugs. If I'm wrong and IMAP support isn't stable now or soon then I don't see much point working on client side IMAP filtering, and would rather focus on fixing IMAP crashes.

If there are some other crashes you are aware of (new crashes) that are reproduceable and seem serious I'm interested in fixing them before moving onto implementing new features. I'm also interested in non-reproduceable problems but there's less I can do about those.

Looking at the list of all outstanding KMail bug reports sorted by vote I see one grave bug #60575, I'm not sure why this is assigned to KMail, and I don't have a (palm) pilot to reproduce it with, it's also unconfirmed. I see 4 major bugs #50707 looks really serious, I believe Till worked on a fix for that (IMAP). #56693 and #61589 are encryption bugs I don't feel responsibility for that subsystem anymore. The remaining major bug #53958 is considered closed by the original reporter, I guess it would be nice to have a time out for pop3 mailchecking, not sure if that is a normal bug or wish, I would prefer to look at this kind of thing once the feature freeze is in place proper.

Then onto the crashes. Ruling out encryption, IMAP and non- reproduceable bugs leaves

57342: I think that's been fixed, just not closed.

57528: Probably a buggy filesystem rather than KMail bug.

58269: Should be a wont-fix I think.

54886,61173,63862: waiting for response

59069,61959: Yes if you run out of ram you'll crash, I would like to continue to improve KMail's handling of large messages post 3.2.

61213: Could do with more work, but it's now a normal bug rather than a crash.

63206: Can't reproduce.

63635: Pass

Looking at the non-reproduceable bugs:

60278, 61226: non-reproduceable pop3 mail checking crashes. Would be nice to spend some time thinking about these but nothing urgent.

61568, 55914 are non-reproduceable index corruption based bugs. Index corruption can't be eliminated, but would be nice to try to implement a better recovery scheme, and improve the corruption detection code, I think that can wait until deep feature-freeze.

You also reported a ghost messages in the outbox problem, that seemed serious.

Looking at normal bugs, none of them strike me as being that important except for Bug:41514 "KMail freezes the UI when checking for new mail". With 631 votes it seem to be the most hated bug in KDE. This is a complicated issue but one of the main problems seems to be blocking actions, specifically piping through spamassassin.

But this bug is actually something I'm trying to solve by working on asynchronous filters. Actually that's the code I'm currently working on in order to make client side IMAP filtering possible!

I guess what I'm trying to say is that I'm not aware of any outstanding reported bugs in my work, or serious bugs in areas that I care about, except for IMAP that is already cared for by others, the spell checking bug that I am currently stuck on, and except for Bug:41514 that I am actually currently working on.

Which is why I'm moving onto new features.

Regarding Bug:41514 unfortunately the new asynchronous filtering system I'm working on is only intended for IMAP filtering and manually applying filters. I'm not intending to port pop, and sending mail over to it yet because it would be way too much work for 3.2. But the good thing about that decision is that it should mean the chance of my work introducing difficult to find/fix regressions is fairly low.

In fact I think for client side IMAP filtering the most dangerous part is done and ready for committing now. I would kind of like to commit that, and work on the remaining part, the ActionScheduler, while waiting for bug reports in the first part. I really need to show Till what I've done so far anyway. I should have an implementation of the ActionScheduler done by next week, and have it ready to commit to CVS by that week or the week after. Then Till and I have to integrate our stuff give this two more weeks. And a GUI change made to make IMAP filtering optional, I would like to keep this very simple for 3.2 just a checkbox in the IMAP account, one week should be ample. That's 5 weeks. (I'm calculating a week as 8 hours work, that's all I have to comfortably spare per week)

Moving onto HTML editing. There's a working (but buggy) HTML editing patch now implemented. It hasn't required any major rewriting of code, so hopefully it doesn't open a can of worms and hopefully fixing the remaining bugs doesn't require any major rewriting. Someone else is helping with this now, so maybe it'll only require two weeks effort on my part.

KOrganizer/KMail integration I really don't see as being difficult from the KMail side given hidden dcop methods, one week should be enough.

Multipart/Related mails might have to slip to 3.3, which is a shame.

So I have 8 weeks / 64 hours of work todo. I'm not sure but I might be able to get it done by the October 21. That is assuming that I can actually get my code into cvs, that it isn't veto'd and that before that date no serious bugs are found, or introduced in the features I've already committed. Which makes me wonder about your finding a new crash every day comment, because I'm simply not seeing regular reports of crashes in the features I've implemented thus far.

Stephan replied that most of the problems he has are with search folders, and had some other comments. Stephan also clarified his position a little further, stating that he would prefer developers to use some common sense in deciding whether to commit features or not, and expands a little upon his reasoning.


3. Apidox patch

7 Sep 2003 - 12 Sep 2003 (17 posts) Archive Link: "[patch] request for review - apidox for kdelibs/kdeui (long)"

People: Brad Hards

Brad Hards wrote:

As part of the KDE developers book, I'm thinking that we should clean up the API reference documentation. I'm not sure about a lot of things, so I'm working this in stages. Stage 1 starts here.

The changes below are from kdelibs/kdeui. They are intended to clean up the "make apidox" output in preparation for subsequent changes and review. The idea is that "make apidox" should build cleanly, so it is easier to find any regression, and that is what the diff below does.

There are four sorts of changes:

I'm mostly worried about the first set of changes, because I don't fully understand the intent of the #ifndef KDE_NO_COMPAT macro, and I worry about binary incompatible changes.

I'm not planning on committing this for at least a week, to provide a bit of time for those recovering from N7Y, but feedback soon would be good, because I'm going to be away (no email after 2200 UTC monday night), and I'd like to fix up any issues, and build on this round of changes.

Most agreed with the patches, except for the placeholders, Stephan asked Brad to either document the functions or don't do anything at all.

cholas Goutte said not to use KDE_NO_COMPAT. Brad didn't quite follow. Nicholas explained. Bad followed. Stephan weighed in. Brad didn't follow again. Stephan explained. Brad agreed violently. Kuba theorized that Stephan is sleep deprived. Stephan didn't disagree.


4. KMail message archiving

11 Sep 2003 - 12 Sep 2003 (7 posts) Archive Link: "Archiving messages from KMail"

CP Hennessy, who is also a self-proclaimed happy KMail user, suggested adding a message archiving feature, apparently time based. Ingo Koöcker noted that that really isn't all that dissimilar to expiring, and maybe to start there, and also that it wouldn't make it into 3.2, regardless. Carsten made a correction but generally agreed with Carsten that this was a pretty good way to go for cheap.

Neil Williams suggested another open source solution, HMonArc. Ingo responded that it probably isn't really a good idea, as using it could risk message loss (KMail doesn't like other apps rooting around in its folders), and also that HTML isn't really the best idea. Neil responded that it works well for him, and extolled the virtues of it. The Editor will have to give it a shot, and if you, the reader, have any experiences with it, maybe post it to a thread on the dot. We'll settle this thing once and for all.


5. audiocd

9 Sep 2003 - 11 Sep 2003 (12 posts) Archive Link: "audiocd"

People: Uwe ThiemRoger Larsson

Uwe Thiem wrote that audiocd doesn't work for him with the error "The file or directory / does not exist". Roger Larsson asked if /dev/sg0 exited. Uwe said yes, /dev/sr0 exists. After it was pointed out that he needs /dev/sg0, it started working. And all were happy.


6. Getting the current directory in a service menu

7 Sep 2003 - 8 Sep 2003 (16 posts) Archive Link: "Getting the currect directory in a service menu"

People: Henrique PintoAaron SeigoDavid Faure

Henrique Pinto asked:

Is there any way to pass the name of the directory that is being visualized in Konqueror to an external app in the "Exec=" line of the desktop file of a service menu? I tried putting "." and "$PWD", but they always expand to the home directory, instead of the current one.

Aaron Seigo responded that you could chop the file name off of the path passed in.

David Faure suggested trying %d. Which degenerated into a discussion of whether to use ; or && in bash. Which turned out to be irrelevant, as both Aaron's and David's solutions appeared to fit the bill quite nicely.


7. Encouraging DB-using applications

20 Sep 2003 - 24 Sep 2003 (47 posts) Archive Link: "Encouraging DB-using applications"

People: Roberto AlsinaGuillaume Laurent

Roberto Alsina asked:

While Qt has gained in versions 3.x a decent support for the development of applications that require access to databases, it is rare to find a KDE app that uses that support.

Why? Because the drivers included with Qt are for databases that require some administration, and thus are not a realistic requirement for a regular user.

What's needed? A driver for an embedded database should be included in kdelibs. That way, we would encourage the development of such applications, much like Visual Basic's embedded DB driver did.

What's proposed? Adding one such driver to kdelibs. I propose qsqlite (http://qsqlite.sf.net). While it has not been too tested, I think it pretty much works (KRecipes uses it, some other app, too), and if it doesn't, it's really a fairly small and simple piece of code.

The only added requirement would be sqlite, which is small, stable and works pretty much everywhere.

Alternatives: Mysql-embedded could be used. I don't know the details, pros or cons about it.

The initial thing that was mentioned is that qsqlite is GPL, while kdelibs is LGPL, and that might conflict.

Guillaume Laurent made the interesting statement that no KDE application has any need for a DB. To which lots of people promptly said "I don't think so!". The point was brought up, though, that databases are somewhat hard for the end user to set up. Guillaume disagreed and said that none of the apps really benefit from using a DB. All of this sparked some discussion, do which Guillaume eventually said that a lightweight DB API would be nice to have, but should be a low priority.

Matthew Chouinard made the point that KDE is a framework used to develop applications, and that a standardized way to access a DB would be beneficial for KDE.

Eventually someone brought up Kexi, to which Roberto replied that that was exactly what he needed.

Concensus seemed to be that an embedded DB engine would be nice to have.


8. development versions

3 Sep 2003 - 4 Sep 2003 (4 posts) Archive Link: "Fwd: developer.kde.org/development-versions"

People: Bernhard ReiterDon SandersStephan KulowIngo Klöcker

Stephan Kulow posted objecting to a CVS commit by Don Sanders stating that disconnect IMAP for 3.2 was too much for him to do, and wondered if anyone could please please please finish the support in head.

Karsten asked if kroupware could do it.

Ingo Klöcker and Bernhard Reiter said they'd see what they can do.


9. KDE 3.2 New Features Article

10 Sep 2003 - 12 Sep 2003 (21 posts) Archive Link: "share your enthusiasm with our users"

People: Aaron Seigo

Aaron Seigo wrote:

with the release of KDE 3.2 approaching, i'd like to put together an article about the NEW things in KDE 3.2. i'll most likely write a small intro (1-2 paras) highlighting KDE in general, but then quickly segway into a trip through All That's New In 3.2 ...

this is not intended to compete with the release announcement or the usual "New Features Guide" release that usually accompanies a KDE release. this is meant to augment them. the intention is to provide a high-speed "from the horses mouth" look at the brand new apps of KDE, of which there are plenty in this release. i also want the article to be a bit more informal, lighter and more fun than the traditional KDE release promo literature.

but i don't want to write it all on my own. not just because i'm a lazy bastard, but because i think it would be really cool for the users of your software to hear your voice. if you've added a new and/or interesting app/ applet/library to 3.2, here's what i'm looking for: a couple paragraphs (at most) explaining what your app does and why it's cool, interesting, useful, whatever. maybe why you wrote it, your favourite feature in it, or who your intended audience is/was. screenshots are also highly desireable.

don't worry about making the text perfect or formatting it.. just send me the plain text and screenies via email and i'll put it all together in time for 3.2 ... if for some reason you don't want your name to appear in a by-line, please note that in your email as well.

below is a list of "new things" in 3.2 that i'd like to include bits on. if you are the author, please consider drafting something up and sending it my way. if i've missed something in the list, which wouldn't suprise me due to the shear volume of changes, don't hesitate to do the same =)

if you've ripped an app apart and/or improved it so radically that it's practically a new app, i may consider including it, but i think that's better served by the New Featres Guide.

Most of the follwoing discussion was about what to include or what not to include, and submitting drafts for news articles. Don't read if you want to be surprised.


10. Adding flac-support to kde-multimedia?

7 Sep 2003 - 12 Sep 2003 (11 posts) Archive Link: "Adding flac support to kde-multimedia?"

People: Allan Sandfeld Jensen

Allan Sandfeld Jensen wrote:

A few days ago I started trying to solve what I considered a bug in juk; that it didnt recognice flac-files as audio. Solving it was simple, but it turned out that we dont have flac-support for arts, so they didnt play. Therefore I have spend an educational afternoon (and night) writing a arts-plugin for flac inspired by the oggvorbis and audiofile-plugins.

Since we went into feature-freeze this week however I am not allowed to commit it directly. That's why I am asking for permission here.

It is in three parts:

The pros of having it in kdemultimedia and not in -extragear or -nonbeta, is that if support is added in juk and it's mimetype added in kdelibs, users might think the files are playable, not knowning it requires an external plugin. And if support isnt added in other applications, the external plugin wont be of much use anyway.

Also of interest is that Kaudiocreator already support encoding to flac.

The only con I can think off, is that it breaks the freature-freeze, but since the code is mostly done and we are still open for outstanding feature-commit, it's hardly a big problem.

Does anyone have any strong emotions about this, or can it be added to the feature-plan?

Most seemed to think it was a good idea, but expressed reservations in that it was not a bugfix but a wishlist item. However, Stephan said that if it's reviewed and tested he doesn't have strong objections.


11. KDE Jabber Server

4 Sep 2003 - 15 Sep 2003 (25 posts) Archive Link: "KDE Jabber Server"

People: Till Gerken

Till Gerken said:

Quite a while ago while googling around, I stumbled across a log of a conversation of (seemingly) people close to the Jabber project, I believe it was a council meeting. They were talking about ways to promote Jabber, one of it was to sponsor a Jabber server for the KDE project.

I've been thinking about this over and over again and Jabber sponsored or not, I think a Jabber server for the KDE project would be a fantastic addition, especially if this would be made in such a way that everybody's @kde.org mail addresses would match their Jabber IDs.

Jabber can be used for instant messaging, news broadcasting (headline ticker etc., so you could get your dot.kde.org headlines in time to your IM program!), file transfer and many more things. It believe it would not only improve communication between developers but also between users and developers.

My thought right now is to restrict the Jabber server to those having CVS write access, be it translators, developers and so on.

I don't know what kind of infrastructure is behind sysadmin@kde.org, so I don't know who should run the server or how it should be run. I'm quite sure that if we'd ask, the Jabber folks themselves would host a server for us or community members would be able to sponsor equipment and service. (Bart and Ian in #kopete were eager to help out)

Oddly enough, and much to the surprise of this editor, there were no disagreements and the discussion rapidly turned to implementation.


12. JPEG 2000

3 Sep 2003 - 4 Sep 2003 (2 posts) Archive Link: "JPEG 2000"

Adam Pigg asked if there was support for JPEG 2000 image format. Sven Leiber (a lover, not a fighter), said yes, there is support for it in 3.2 and in CVS.


13. kdeaccessibility module as official part of KDE

29 Aug 2003 - 5 Sep 2003 (13 posts) Archive Link: "kdeaccessibility module as official part of KDE"

People: Gunnar Schmi Dt

Gunnar Schmi Dt said:

On the kde-accessibility mailing list we agreed that we want the kdeaccessibility module to become an official part of KDE 3.2.

Currently the kdeaccessibility module contains the three applications KMagnifier, KMouseTool and KMouth. All three are quite stable.

Planned features are a window decoration with wide borders and a widget style that avoids hard-codeed widget sizes (as the height of horizontal scroll bars) and interfers correctly with the the high contrast color schemes (especially with the white-on-black color scheme)

There did not appear to be objection, just some implementation-based feedback.

14. kde-cvs mailinglist reorganization

9 Sep 2003 - 10 Sep 2003 (11 posts) Archive Link: "kde-cvs mailinglist reorganization"

People: Rob Kaper

Rob Kaper said:

I have 10,000 unread messages in kde-cvs and it bothers me. I realize I could set up client-side filters, but that would still be a waste of bandwith for both me and KDE.

A couple of the options that have crossed my mind (and were briefly discussed on the bus to Frankfurt from N7Y and previously on this list):

My personal preferences goes to the first option: loginfo isn't a bitch to maintain (I'll gladly do it) and running a few more mailinglists won't be a disaster either, especially not because this change will safe tons of bandwidth for all involved.

I'd like to suggest making a relatively small change first: seperate the kde-i18n e-mails. I'm willing to bet the majority of kde-cvs readers already have a procmail or KMail rule to get rid of these ASAP and it wouldn't hurt putting those on a seperate mailinglist (and not keep them on the regular kde-cvs).

On the long-run I think a module-based seperation is a decent compromise. It works for discussion, after all. I'm on kde-games-devel, not kmail-devel, so to me it would be perfectly logical to be on kde-games-cvs and not on kmail-cvs.

All agreed that it's a problem, and several suggestions were put out to deal with it, some agreeing with Rob, and others with ideas that work now.

15. Libkdenetwork unification

3 Sep 2003 - 7 Sep 2003 (4 posts) Archive Link: "unifying libkdenetwork/syntaxhighlighter and kdeui/ksyntaxhighlighter"

People: Scott WheelerZack Rusin

Scott Wheeler said:

Here's another leftover from the conference that it would be nice to slip under the feature freeze thing. :-)

This one's pretty simple -- kdeui/ksyntaxhighlighter was based on the similar class in libkdenetwork. The APIs are still the same except for one method, which I'm including in this patch.

One of these is being used for KMail and KNode, the other for KHTML and friends.

I'd like to apply the attached patches to KMail, KNode and the class in kdelibs, and remove the one from kdenetwork.


No one objected except for Zack Rusin, but he doesn't count :) Seriously, he did note that the patch broke the suggestions for misspelled words, but didn't feel he had the right to complain because he was late with the objection, so he fixed it.

The unification is complete. Muahahaha.







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.