While we anxiously await the release of KDE 2.2in 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.

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.

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

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.

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

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

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.

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

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.

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

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.
--
Cheers,
Jeff

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.

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.

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.

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!

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.