KDE Traffic #75 For 27 Feb 2004

By Henrique Pinto

If you like KDE Traffic, please consider making a donation to the KDE Project. Visit http://www.kde.org/support/ for details.

Table Of Contents



This is KDE Traffic, issue 75. You have probably noticed KDE Traffic isn't being issued regularly. If you're interested as to why it is happening, I'll explain at the end of this issue.

Since KDE Traffic #74, a lot happened in the KDE community. KDE 3.2 was released (as you probably already knew), KDevelop 3.0.1 was released too, the HEAD branch was reopened for non-bugfixes commits...

1. Image Viewers [kde-core-devel]

29 Jan 2004 (10 posts) Archive Link: "changing priorities"

Topics: Development Plans

People: Matthias KretzSimon PerreaultGuillaume Laurent

Matthias Kretz announced:


since quite some time I've been a lousy KView maintainer. I know of a lot of problems and sometimes even how to fix them. What I'm missing is time and motivation to work on it. I'll be available to answer questions if anybody wants to work on it. If you think KView is outdated (enough image viewers out there) we should take a look at replacing the KPart functionality KView is providing. Also I started to work on a KImageViewer interface that I never finished that would also be nice to have...

For the time after 3.2 I'd like to concentrate on Multimedia for KDE 4. That's the subject I'm really interested in and I believe we have a lot of work to do to get it right for KDE 4. If there are other people interested let me know, we should start discussing it and producing code as soon as possible.

Simon Perreault replied:

I've been working for some time on replacing KView's canvas part with something that would be

  1. Faster
  2. More accurate
  3. Faster
  4. Well designed

I have already done that. However, I found that all of KView is in fact not very well designed. It tries do to too much, being a library, abstract API, kpart and plugin-based program at the same time.

I have therefore started KCDSee, with the aim of it becoming the main light-weight KDE image viewer. It is already much faster than anything out there (be it kview, kuickshow, gwenview, or even *gasp* the gimp). It uses KImageIO only, which makes it integrate easily. It is a kpart, so it can be used by konqueror to show images. It is still not full featured though. The viewer part is almost done, but the program needs some bells and whistles.

What I propose: I would like to become KView's new maintainer, as I am now quite accustomed to the code. I don't propose that I actively work on it, that's best left to other contributors. But I know I can maintain KView well. At the same time, I'll continue work on KCDSee (you have an idea for a better name?) so that it becomes good enough to replace KView. What do you think?

Guillaume Laurent suggested Gwenview as a replacement, but Simon Perreault didn't like the idea much:

A replacement to what? KView? Why not Kuickshow?

KView is not the KDE image viewer. It is not even the kview kpart that is used to view images in konqueror, it is the "embedded image viewer", or something like that, which has zero features, and which I suspect of using KHTML for displaying images.

Adding Gwenview is cool, but I don't think it should replace anything.

I agree that there should be only one image viewer in the base kdegraphics package, and all others should be in kdeextragear. And please, before making that decision, wait until KCDSee is done.

No consensus was achieved.

2. Composing HTML messages in KMail [kmail-devel]

8 Feb 2004 - 20 Feb 2004 (20 posts) Archive Link: "[PATCH] composing html messages"

Topics: KMail

People: Edwin SchepersCornelius SchumacherDon Sanders

Being able to compose HTML messages in KMail has been the most wanted feature for ages. Edwin Schepers announced a patch introducing that feature:

Finally it looks I have something workable.
It's not final: indentation, deleting some kDebug's and naming has to be changed.
Could you (someone) review ?
If this is the way to go, and when it looks quite stable, can I commit (after the changes to make it final)?

This feature also requires a small patch in kdelibs/kdeui/ksyntaxhighlighter. Would that be a problem for kdepim-3.3 ?

Cornelius Schumacher pointed out that KDEPIM 3.3 must work with kdelibs from KDE 3.2, and as such the KSyntaxHighlighter changes were not possible. Edwin proposed another patch, without the need to modify kdelibs. Don Sanders asked for some clean ups before the patch could go into CVS, and Edwin proposed a new patch with those clean ups made:

This is a new patch.

Issues to be solved :

I hope these issues won't stop my patch going into cvs.

There were some concerns regarding signing/encryption support. The current version of the patch does not support them at all, it seems. It was pointed out that it might break support also for non-HTML messages, but Edwin clarified:

the patch does not break signing for non-HTML mails. Signing is not yet supported for HTML mails. When trying to sign an HTML mail, the user will be asked what he wants to do :

  1. sign it and remove the formatting or
  2. don't sign and keep the formatting.

If signing is default on, the user will be asked a similar question when he/ she wants to use formatting.

This will be my first patch, so I don't know when the time is ripe to commit. I am waiting for a go from someone...

Elsewhere, Ingo Klöcker stated that the patch could go in as soon as signing HTML messages with OpenPGP/MIME and S/MIME works, but that would depend on a redesign of some of KMail's internals.

3. Search Bar for Konqueror [kfm-devel]

8 Feb 2004 - 9 Feb 2004 (6 posts) Archive Link: "Search Bar for Konqueror"

Topics: Konqueror

People: Arend van Beelen jr.

Arend van Beelen jr. announced:

I created a Search Bar plugin for Konqueror. If installed, this plugin will effectively create a second combo box next to the location bar. Much like the Google Bar as seen in Mozilla Firebird. The actual search is done using the default search engine as set up under the Web Shortcuts section in the Konqueror configuration. Also, it will display a small icon to show the search engine it uses. If no-one has serious objections to this plugin, I will add it to CVS.

Luís Pedro Coelho remembered that it is possible to type searches in the location bar, but that feature was hidden. He was also concerned that adding another combobox would have an impact on the screen space. Mikolaj Machowski pointed out that if the search bar was put beside the location bar (and not under it), no screen space would be wasted. The search bar plugin was then imported into CVS, as part of kdeaddons.

4. KDE's Future [kde-core-devel]

4 Feb 2004 - 19 Feb 2004 (120 posts) Archive Link: "Re: [kde-announce] Announcing KDE 3.2"

Topics: Development Plans

People: Brad HardsStephan KulowHarald FernengelRob KaperMarc MutzWaldo Bastian

Just after the 3.2 release, Brad Hards wrote:

I understand that KDE 4.0 is intended to be based on Qt 4, which is perhaps still some time away, so we are probably doing a KDE 3.3 release.

I see KDE 3.3 as a shorter release (perhaps 6 months?), with fewer new features than KDE 3.2 provided (that is, KDE 3.3 - KDE 3.2 < KDE 3.2 - KDE 3.1 in features terms).

Should we begin planning both 3.3 and 4.0? Do we have a RD for 3.3? Can we start roughing out a schedule?

And is there any chance that we can ship KDE 3.3 in konjunction with the proposed kdepim 3.3 release?


Stephan Kulow replied:

For me there are two things that would justify a quick KDE 3.3 release for me:

I haven't heard about the Qt atk bridge again (and afaik it's not part of the Qt 3.3 changelog), that would have been another reason.

But 6 months is unrealistic. You end up with a release in august and that's exactly the time where many of the nothern hemisphere are relaxing in the sun and don't care about hacking. And less than 6 months is pretty unrealistic too, taking that we spent roughly 3 months in feature freeze for 3.2.

So I think, we still need to see how much impact Qt4 has on our code base and then we can schedule again.

Regarding the Qt-ATK bridge, Harald Fernengel spoke: "I'm actively developing it on Qt 4 and porting it to Qt 3.3 in my spare time (which is not much and requires crude hacks ), a snapshot can be found at http://trolls.troll.no/~harald/accessibility/. Moving quickly to KDE 4 would allow us to break BIC in kdelibs where it is needed for the accessibility stuff." But Rob Kaper complained: "We moved to Qt3/KDE3 quickly for BiDi text support, and to have a long-lived binary-compatible 3.x platform for third-party developers to develop against, which more or less prevents us from using the same argument again for 4.x." Coolo remembered that KDE 3.0 was released on 2002 and KDE 4.0 can't be released before 2005, and that's "long-lived" enough.

Later, Marc Mutz proposed a 3.3 release focused only on applications, that would run with kdelibs 3.2, while kdelibs HEAD would see some cleanups for KDE 4.0. In his opinion "KDE should start faster release cycles for the application modules and back up a bit on framework releases. 1+ year cycles for kdelibs and ~6 months cycles for applications would create a climate where applications could progress faster and the framework be more polished. This is because on the app side, you get user feedback faster, and on the libs side, you need to think twice before adding something to it if the next kdelibs release won't be in time for the next release of your app. New classes could prove themselves in the lib<module> libraries before being moved to kdelibs." Waldo Bastian posted, stating that he agreed with Marc, but it wouldn't be possible to skip kdelibs 3.3 because KHTML is part of it.

Elsewhere, there were complaints about the number of non-implemented old wishlist items in bugs.kde.org (http://bugs.kde.org) . Stephan Kulow said that he will start a project to expire wishlist items that got not enough votes in enough time. There was then discussion about which reports should or not be closed.

In the end, there was no conclusion regarding having or not a KDE 3.3 release, nor when it would be released if so. But given that KDE 3.2 was just released and we are still on the beginning of the release cycle, there's still time for deciding that.

5. KDE Edu 3.3 plans [kde-edu]

18 Feb 2004 - 19 Feb 2004 (13 posts) Archive Link: "[kde-edu]: 3.3 planned features"

Topics: Development Plans

People: Anne-Marie MahfoufKarl-Heinz Zimmer

Anne-Marie Mahfouf posted a list of issues regarding kdeedu:

Here are some issues I would like to address for 3.3 as we must see what we'll do for kdeedu. Please see here http://edu.kde.org/development/apps_features.php for updating your TODO and have your planned features written. This page is generated from the todo.inc on your webpages.

General issues:

Kiten: is there still a maintainer?
KMathTools: is there a mantainer? if not, must go away from the module
KTouch: is it still maintained?
KEduca: is it still maintained?
KMessedWords: no maintainer?

Kalzium and KVerbos are being rewritten by their authors.

KStars and Kig are totally up-to-date, doc, webpages, TODO, everything is well maintained. i18n("BRAVO!")

KHangMan and KLettres will be trimmed and will use KNewStuff, I am waiting for KNewStuff to join kdelibs.

KWordQuiz is likely to replace FlashKard.
KTurtle is likely to get in (it's going to FOSDEM next week-end, we'll get some feedback from there) (kdenonbeta/kturtle) What other big changes are we expecting?

There was some asking that QWhatsThis help must be implemented for all progs so let's do this. Plus some docs are a bit out-of-date.

What I suggest is to list on a different page all tasks that we think should be done but that we cannot do ourselves for our app(s). David is working on icons but we can list the ones that still have to be done. We can list the docs, the WhatsThis, porting to KConfig XT and so on. I started something here: http://edu.kde.org/development/open_tasks.php

Thanks for debating on all that and giving your point of view, I am just here to make suggestions and keep the project up-to-date, I need your full support :)

Karl-Heinz Zimmer pointed out that there were some planned features for KVocTrain, but the didn't know their status. Samuel Desseaux stated that he was working on it.

6. What happened to KDE Traffic?


Since the beginning of this year, as you might have noticed, KDE Traffic has not been issued regularly, as it used to be. I've been receiving a lot of messages from people worried about its future, so I'll try to explain things here.

I enjoy writing KDE Traffic. I don't plan to stop doing that soon. So, KDE Traffic is not dying. At least not now. But it might still take some time before I'm able to regularly write it again.

Near the end of January, I had severe hardware problems. Almost all parts of my only computer system were damaged. I didn't have enough money to buy everything needed, so I still have no printer, no soundcard and no Internet access at home. While the printer and the soundcard are not crucial for writing KDE Traffic, an Internet connection surely is, as I need a way to get the email messages I summarize here.

Currently, I'm reading mail at a friend's house, but there I'm limited to Windows 2000 as OS and Thunderbird 0.5 as MUA, not the best setup possible for me. Because of that, writing KDE Traffic is being nearly to impossible these days. Due to unplanned expenses I recently had, this situation might extend until the end of March, as by that time I'll already have money for buying a new modem.

Another issue is that I'm having almost no free time lately, and because of that KDE Traffic is still limited to a few mailinglists (kde, kde-accessibility, kde-announce, kde-core-devel, kde-edu, kde-extra-gear, kde-i18n-doc, kdepim, kdepim-users, kde-usability, kfm-devel, kmail-devel and koffice-devel). Covering more mailinglists would be nice, but unfortunately it is impossible for me. If anyone regularly reads one of the other lists and could write a small summary of the interesting threads from time to time, help would be very appreciated.

Thank you!







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.