Proposed Timetable for KDE 3

While we anxiously await the release of KDE 2.2
in two weeks,
Waldo Bastian,
the current KDE release coordinator, has
posted the proposed schedule for the release of KDE 3. The upshot:
KDE 2.2.1 is scheduled for September 2001 and KDE 3.0 for January
2002. The full schedule is available below.


  Waldo Bastian <[email protected]>

  [email protected]

  RFC: The Road Ahead

  Mon, 23 Jul 2001 14:07:01 -0700

To wrap up the Qt3 discussion and to bring everyones expectations a bit in
line, here is a proposed time-table for the rest of this year:

  • Aug 2001: Release of KDE 2.2
  • Sep 2001: Release of KDE 2.2.1
  • Oct 2001: Development release, KDE 2.89 aka Qrash3.
  • Nov 2001: KDE 3.0beta1
  • Dec 2001: KDE 3.0beta2
  • Jan 2002: KDE 3.0 final

I suggest to switch KDE CVS to Qt3 after the release of 2.2.1.

If you would like to be the release dude for KDE 3.0, now is a good time to
step forward :-)

Andrei Sakharov, Exiled 1980-1986, USSR,
Dmitry Sklyarov, Detained 2001-????, USA,

Dot Categories: 


by kde-zealot (not verified)

There is a saying ...

Vision without action is fiction

Three cheers for KDE for keeping me in the NON-fiction part of the library :)

On a side note .. the funniest thing about the new KDE site is the hyperlink which reads Humour. The link points to

Now THAT was funny!

by philiKON (not verified)

... and :wq links to

by john (not verified)

my god.

6 months until KDE3.0?!

don't you people have lives?!?!



can't wait for it.


by Konrad Wojas (not verified)

How about KDE2 programs? Will KDE3 be source comaptible with KDE2? Will I/O slaves written for KDE3 also work with the KDE2 programs or do you have to maintain a separate set of I/O slaves?

I'm looking forward to KDE3, but I hope some attention will be given to backward compatibility with KDE2...

by David Faure (not verified)

I don't expect the I/O slave system to change except for a very small cleanup.

For the rest it's hard to tell, the porting hasn't been done yet.

The plan is _not_ to re-engineer everything as happened during the 1.x->2.x switch, so the porting should be quite easy.

Don't expect binary compatibility though, recompiling will be in order.

by M. Khawar Zia (not verified)

what features will kde 3 have???

by Dre (not verified)

If you want a lot of details you can read the thread at

The executive summary: the intiial kde 3 release will just be a port of KDE 2.x to Qt-3, with the usual set of feature enhancements that accompanies a KDE major release (e.g., like KDE 2.0 to KDE 2.1).

Qt-3 offers some significant advantages over Qt-2, including bi-directional text support (for Arabic and Hebrew), database-aware widgets, QTable, etc. Of course there is also the rich text widget and the "html" widget, but at least the rich text widget has been backported to Qt-2 for KOffice already.

Also, porting KDE 2 to qt-3 will be *a lot* easier than it was to port KDE 1 to qt-2. The changes are far less drastic; some have reported porting complex and large applications in just a few hours. Plus KDE itself is not getting rewritten, as was the case for KDE 2.

The thread also gives the reason for switching to KDE 3 so soon. Most distributions will upgrade to gcc 3.0 and the accompanying libstdc++ in the near future. This will break binary compatability for all KDE programs. Also gcc-3.1 is again to break binary compatability, this time for libstdc++ only. Thus the idea is to switch to KDE 3 right along with the gcc 3.1 release so that binary compatability is not broken a third time with KDE 3. It does break source compatability, but as noted above it is not difficult to port to Qt-3 from Qt-2.

by John (not verified)

Wow, that thread makes for facinating reading. A nice, reasoned exchange of ideas until a sensible plan is developed. A great example of how the Open Source model is supposed to work.

Props to the guys for professional way they've attacked the problems involved.


by Victor Röder (not verified)

How does the new component model play a part in KDE 3?


by Eeli Kaikkonen (not verified)

>Thus the idea is to switch to KDE 3 right along >with the gcc 3.1 release

Cannot be 3.1, KDE 3 was proposed to be ready in January 2002, gcc 3.1 is scheluded for April.

by someone (not verified)

Some developers started to scribble down their plans, of course this is not complete:

by dude who cares (not verified)

I think it would be beneficial to everyone if we had an update system built into KDE.

after KDE2 came out, we had update after update after update, without really a way to upgrade kde2.0 to 2.0.1, then 2.0.2 then 2.1 then 2.2, and all the beta's in between that.

Is there anybody working on a live update's package for KDE2 that can take binary packages, download them, and install them into the KDE directory for you. You would still use the system's package manager, but not for updates. KDE would take care of all that for you. Only use the distribution's package manager when doing a new install of kde, or when doing a major upgrade (ie, kde2x to kde3x)

This would also put KDE on a lot more desktops of willing beta testers. And can keep people from the kde2x series up to date, without having to re-do their whole KDE installation.

i hope you like this suggestion


by wizdom (not verified)

kdeinstaller does (or at least aims to do) something similar already.
It's in the kdenonbeta directory of the main CVS repository.

Haven't tested it myself, good luck.


by Steve Hunt (not verified)

The KDE Installer Project was halted by its fearless leader, Nick Betcher. Their website is at

by Corey (not verified)

I dont think that this is within the scope of KDE. Also this is duplicating what decent distros already do. Try using Debian, "apt-get update; apt-get dist-upgrade". Plus, if you want a GUI to do it for you there is kpackage. I'm sure that sometime soon the other distros will catch up to what apt has been doing for ages.

by dingodonkey (not verified)

As far as I am concerned, that should be up to the OS distro including KDE. They mostly all have their own update programs anyway, best keep it simple. And if you know enough to get KDE set up on a system that didn't come with it, you know enough to update yourself. That would just bloat things more than they need be.

by Alain (not verified)

> As far as I am concerned, that should be up to the OS distro including KDE. They mostly all have their own update programs anyway,

No, they have not any an easy way to install. Only a lot of rpm, with bad dependencies to manage.

So a kdeinstaller would be useful.

Good thing this KDE 3 calendar, I am happy to see the dynamism of the KDE team ! Changing sooner is a sign of leadership. Good luck for many powerful improvements !

by Psiren (not verified)

> No, they have not any an easy way to install. Only a lot of rpm, with bad dependencies to manage.

Yeah, cos RPM based distro's suck. As said above, use Debian. Dependencies are dealt with automagically.

by Alain (not verified)

> As said above, use Debian. Dependencies are dealt with automagically.

Sorry, I want something user friendly (and, about it, Debian sucks, as you said...) or I wait...

Now I wait, I install KDE only with a distrib new version.

by Gregory W. Brubaker (not verified)

this might become a flame war... hehe...

Anyway, KDE runs on everything... not just linux... and linux, as well as the other operating systems don't just run on intel processors...

It would take a large team to support this many binary update schemes...

Personaly, the operating system ( or in Linux's case, the maybe the distro maker ) should probably handle this...

After all, just because KDE developers are on steroids (They take it in tea form), doesn't mean they don't (ever) sleep...
New Thought:

Man did we all notice KDE spinning along last Fall/Winter. Many of us didn't believe they would be able to release on schedule, with what they had planed, and do it all so well. Now, we know it will be done, and can just stare in ammazement... However, don't forget you too can join these cool guys, and help out however possible...

by Evandro (not verified)

Conectiva has APT and Mandrake has URPM to handle dependencies automagically. And they´re both rpm-based distributions.

by David Ludwig (not verified)

One possible solution to this would be to have an updater/installer GUI interface with multiple backends. One backend for Debian, one for RedHat, one for SuSE, etc.

by Rick Kreikebaum (not verified)

or a common backend like the ximian setup tools or something that all the distros could later adopt

by Peaker (not verified)

Debian's apt-get dist-upgrade seems to keep me in line of the newer KDE packages pretty quickly already :)
If anything, just post new .debs every day?

by antialias (not verified)

Aka Qrash3? Joke? :)
When I pronounce Qrash it sounds like 'crash'.

by Jerome Loisel (not verified)

KDE 1.89, the first 2.0 pre-release, was code-named "Krash". The intent was to let everybody know that this was a very early beta of a whole new KDE architecture and was therefore still unstable. Think "technology preview".

This time, of course, the new technology will mostly stem from the new Qt version... Hence the name "Qrash". But it's mostly for laughs. :-)

by AC (not verified)

Great news. I have been hoping they would opt to switch to Qt 3 sooner rather than later.

by Asif Ali Rizwaan (not verified)

KDE 2.1.1 is still very much slower than Windows or say KDE 1.1 which was very fast. Here is my observation:

1. Explorer takes 2 seconds in windows 98
2. Konqueror takes 3 seconds in KDE 2.1.1
3. KFM file manager/broweser took 1/2 (half) second.

KDE Updates should be Statically linked binaries like windows Internet Explorer, Windows Media Player, etc., upgrades. Other than that Opera Browser is a good example for Linux.

All I want is KDE 1.1's speed in KDE 2.2 or KDE 3.0. Have the developers Optimized the KDE code!?

by Asif Ali Rizwaan (not verified)

> 1. Explorer takes 2 seconds in windows 98
> 2. Konqueror takes 3 seconds in KDE 2.1.1
> 3. KFM file manager/broweser took 1/2 (half) second.

1. Explorer takes 2 seconds in windows 98 _to appear_ after click.
2. Konqueror takes 3 seconds in KDE 2.1.1 _to appear_ after click.
3. KFM file manager/broweser took 1/2 (half) second _to appear_ after click on the associated icon.

> Other than that Opera Browser is a good example for Linux.

Other than that Opera Browser is a good example for Linux which gives statically linked application. I used that on RH 6.2.

The speed penalty is in big parts due to the linker (ld). Waldo Bastian analyzed the problem and now somebody from the ld team is working on it. I read first numbers which said a first alpha version of the improved linker reduced the time needed for linking on his machine from 0.6 to 0.01 seconds. This sounds very promising :-)
The second thing is the slow icon loading, I will have a look at it.


by kde-user (not verified)

Is this at all possible?

(I don't expect it to be done, but just from a wish-list point of view)

I would rather buy another 128mb DIMM RAM so that the entire KDE could be run from RAM so that everything is already loaded.

Why can't we have this as a solution for people NOW that can afford it?

I would love that as the solution for me :)

by Fred (not verified)

I don't think that RAM is the answer, since I've tried that solution myself. I doubled my RAM from 128 MB to 236 MB - I know that it isn't a huge amount of RAM - but it still ought to make a difference - and that's my point: I didn't for me... So I'll look forward to see Waldo's paper turned into code i KDE 2.2 /Fred

by Fred (not verified)

Let me try again : ) 128 MB + 128 MB is 256 MB all those numbers...

by Carl R (not verified)

I recently upgraded my ram from a puny 64 megs to a total of 320. Starting times of kde apps are somewhat better, but this is mainly due to the fact that I don't have to hit swap anymore.

I'd imagine there might also be some slight improvements just because previously accessed files (including binaries for the apps) get cached in ram, making the second load faster. I don't really know enough about how Linux does this to accurately comment, though.

Hopefully the loader issues get sorted out soon, though; the effect of it currently is fairly noticable on a 350MHz cpu.


by Justin Hibbits (not verified)

Hmm...I have 256MB and I hit swap all the time. Maybe something's wrong. Running Potato, X 4.1.0-4.0.1 "hybrid", Kernel 2.4.5, 57 MB Swap, and ran completely out once, had to kill X, then went down to 3 MB used. What could the problem be? Probably my celeron...maybe on my 1.0GHz Thunderbird things will change.......

by Jeff N. (not verified)

IIRC, Linux kernels in the 2.4 series prior to 2.4.6 had some memory management issues. I noticed these myself... After going from 2.2.18 to 2.4.2, memory use on my 128MB Athlon 600 system really seemed to *not* perform as well as with 2.2.18.

I upgraded with each new 2.4.x, and now with 2.4.6 memory usage has really improved! Yay! =)

If you are still using 2.4.5, try upgrading to the latest kernel and see if that helps...

IIRC, there was something about it (the kernel) not releasing allocated memory when the memory was no longer being used..? Can't say more because I don't know all the details.

by Carl R (not verified)

I'm still running 2.2.19 until I either find a compelling reason to switch, or I decide to play with a new distro that has a 2.4.x kernel.

I *think* the problem with the 2.4 kernels up to 2.4.5 was that they would allocate pages in swap, but not always *de*allocate them. This would cause any machine to eventually run out of swap space. I could be remembering this wrong though, so check Kernel Traffic for details.

by Dieter Nützel (not verified)

I would suggest all of you to switch to 2.4.7, as soon as possible.

With it most VM issues are fixed (some more optimizations are under development).
Linus et. all. are very pleased with it.

Even most of the outstanding ReiserFS fixes are in place, now (NFS).


BTW I have 640 MB but it is NOT the answer to all questions...;-)

by Gunter Ohrner (not verified)


Are you using imported GTK pixmap themes? I don't know if that has been fixed but in times of KDE 2.0.x there was a huge ressource leak in GTK pixmap theme handling.
Additionally I must say that I still have memory consumption problems although I dropped my favourite GTK theme quite fast. (at least for KDE...) I have 512 Mb RAM installed in a DualCeleron 466 machine running Linux 2.4.6, glibc 2.2.0 and X 4.0.3 / 4.1.0. X often uses more than 200 MB RAM, sometimes even causing my machine to page out memory... :-(
Kernel 2.4.6 seems to perform substantically better than the previous 2.4.xs.


Gunter Ohrner

Nope, I never use Gtk+ themes, since there are KDE themes that are close enough, so I use those. Now I use KDE 1, but parts still seem to be a little slow. Oh, well. Ever since I upgraded to kernel 2.4.7 yesterday, it hasn't gone to swap at all. Also, it actually found my power button -- what would it do if it didn't, panic? (lol)

I am still keeping KDE 2.1 on my computer, but just the libs and some programs like Konsole because they are better than the KDE 1. I just need to find a patch for Qt 1.44 that supports the wheel. Then I'm all set.

by Carl R (not verified)

aleXXX wrote:
> The speed penalty is in big parts due to the
> linker (ld). Waldo Bastian analyzed the
> problem and now somebody from the ld team is
> working on it.

Does anyone have a link or other reference as to what's currently being done? I don't know if I'd really have much to contribute, but being the curious type, I'm sure following the development of this would be about as much of a learning experience as reading Waldo's paper was!


by DavidA (not verified)

Thanks, nice links. I wondered if anything came of this after Waldo's paper and actually I'm still wondering if anything will actually happen with this code?

Has anyone actually tried this and if so what results did you see in the real world; could you tell the difference when using the pre-linker?

Any ideas what timescales we are talking about till this goes mainstream and this distro's use it?

by JP (not verified)

So when well we have Arabic or hebrow support?!
it's about time .. :)
i mean eaven if it was a beta ver. when do you think that KDE well support Arabic and Hebrow (BiDi)?
KDE always rocks :)

Thanks and keep up the GOOD work ;o)

by David Faure (not verified)

Arabic and Hebrew support is one of the primary reasons for switching to Qt 3. So expect this to be available starting from KDE 2.89.
I'll make sure KWord supports it.

by JP (not verified)

David this is the best news i have heard in a long time..

just keep up the good work!
you guys are great!


by Abdullah (not verified)

Thanks a lot for the Arabic support.
This is one thing that keep me using MS OS and application on my desktop. with this support I will switch to only linux desktop.

Will Arabic support be available for all KDE applications?


by Amer (not verified)


I am very happy to hear about Arabic support in KDE.

but please try to fix up the arabization faults M$ did in their Arabic Windows System.

I hope you finish your work perfectly.

Please consider implementing some special Arabic typefaces issues in the KWord to correct the bad shapes of some combinations.

Please tell me if you need a description about the advanced shaping problems in Arabic typefaces.

thank you very much.

by Claes (not verified)

KDE is sure moving quickly. And that is in some ways good. But in this fast speed, will KDE ever be able to mature and become truly stable? I fear that there always will be serious bugs if there is so little time to maintain a stable release before it is time to release the next major version. Compare to the Linux kernel. Even though there are newer development kernels, the old ones are maintained a long time. I wonder if it should not be better to aim for the next release much further ahead in time.

by Tom (not verified)

I could not agree with you any less. I rather have KDE 3.0 between June-July next year rather than early next year.

More times on development means more stable, better product and less pressure on those KDE teams...

All the best ..

your biggest FAN