Hi,

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.

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?

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.

Hi,
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 ?

This is a new patch.

• #define DEBUG deleted
• messagebox when trying to sign/encrypt HTML messages
• code cleanup
• html toolbar off by default

Issues to be solved :

• line spacing when opening and closing from Drafts
• signing/encryption of HTML messages
• opening HTML messages from Drafts does not always show a correct message (it's including the HTML code). This has to do with the fact that the bodyParts are not always the same. It seems that it differs depending of whether another message is clicked before.

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

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...

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.

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?

Thoughts?

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

• Cleaning up kcontrol in introducing the long awaited theme manager and moving out the app specific modules (you know where I am, Scott :)
• Profile enhancements for konqueror, that were floating around shortly before release (#74097 is just another incarnation of that wish)

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.

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 :)