KDE 3.1 RC2: Ready For A Hammering

The KDE Project today released KDE 3.1 RC2, probably
the last release candidate for KDE 3.1.
A good number of showstoppers in RC1 have been fixed, and the new default Crystal-SVG icon set has been polished based on the valuable feedback received. Nevertheless, please give this RC2 another round of thorough testing to make sure all the major wrinkles have been
ironed out. Please note that the kdebindings package still suffers from
compilation problems in large parts, but this will be fixed by the final
release. Thanks to the community for the feedback so far, let's keep it up
and make the 3.1 release everything that is expected!

Dot Categories: 


by NewMandrakeUser (not verified)

I almost tried it. But rpmdrake would only offer to update some kde* packages, and _not_ qt. It didn't look good (of course it is perfectly OK for cooker to be broken) so I decided to wait for 3.1 final. There will probably be ML 9.0 binaries posted by then, and it'll only be one or two weeks from now I hope ...

by isNaN (not verified)

works beatifull!

Just remember to upgrade libqt3 else if will fail horribly...

by Paul PARENA van Erk (not verified)

Just download all KDE 3.1rc2, (lib)QT and Arts packages to a directory and do urpmi *

If there's anything missing, it will notify you. Just download that RPM, put it in the same directory and try urpmi again...

I love urpmi :)

by Shamyl Zakariya (not verified)

I'm curious about qt3.1 which will be used in KDE 3.1. What's different? Have the fontconfig and xft2 patches been applied and tested?

I'll find out when I get home from work, as I set it all to build before I went to sleep last night (and it was still churning when I left for this morning ;)

Nonetheless, I'm curious about changes in qt 3.1

Anybody care to enlighten me? The trolltech pages weren't as detailed as I'd hope.

by Rayiner Hashem (not verified)

Yes, Xft2 and FontConfig both accounted for. Aside from that, it's a maturity release. Things seem to be just a hair smoother, stuff is a little more polished, and Qt Designer has a *much* more friendly interface.

There are two changelogs here:

by Shamyl Zakariya (not verified)

I'll have to experiment with how qt3.1 is compiled -- it's probably a matter of configure options. I'm running rc2 right now, thanks to Gentoo, but I've had several apps crash, and on the backtrace it's obvious it's font related. The drawback to gentoo is that the simplicity of its build system removes you from the process of examining the output of ./configure --help so you can pick the best options.

Well, more time spent compiling...

by Rayiner Hashem (not verified)

I'm using Gentoo as well. RC2 has been rock solid so far, not a single crash. But if you want, you can examine the output of configure. Just go to the ebuild you want in /usr/portage. Say you want to configure qt-3.0.5-r1.ebuild. Go to /usr/portage/x11-libs/qt, then type 'ebuild qt-3.0.5.ebuild unpack' This will unpack the sources to /var/tmp/portage/qt-3.0.5-r1. Go to that directory, than to 'work', then to 'qt-3.0.5' (or whatever directory the sources get unpacked to), and do your ./configure and make. After the make is complete, do an 'echo " " > /var/tmp/portage/qt-3.0.5-r1/.compiled' (ie, make a file called .compiled, with any contents, in the top level directory for the particular ebuild). Now go back to the ebuild, and type 'ebuild qt-3.0.5.ebuild merge' Portage will detect that you compiled the package yourself, skip the unpack and build steps, and merge in the compiled package.

by rbh (not verified)

Now this is a gem for us Gentoo users! Thx

by Shamyl Zakariya (not verified)

Fantastic -- I've been running gentoo since april or so and while I love it, I do treat the build system as magic pixie dust and pretty much leave it alone. When I need to compile something custom, I have copied its archive from /usr/portage/distfiles and (re)built it myself. For example, just two days ago I rebuild kdelibs and kdebase to use the really cool menubar kicker applet at http://lists.kde.org/?l=kde-devel&m=103644337025010&w=2 (I can't figure outhow to make a link on the dot). If I had known I could unpack the sources, tweak them, then let portage install them and not confuse its timestamp system I would have.

Thanks for the instructions. Portage is great, but almost too featureful for me to properly use -- I'm really much more of a slackware type ;)

by Janne (not verified)

Is any work being done to make KDE work with prelinking? It seems to be that one of the biggest gripes people have with KDE is the slow startup of apps. Prelinking would eliminate that problems. The problem is that KDE doesn't work with prelinking.

by Mita (not verified)

Sure does.
Fetch latest prelink from ftp://people.redhat.com/jakub/prelink
It is part of RH8.0 too

by Janne (not verified)

It does? Then what is this about:


Or is it that Xfree doesn't work with prelinking? Anyone here run prelinked KDE? How's the performance?

by repugnant (not verified)

From what I understand the binutils 2.13 enable some kind of prelinking by default. I tried the prelinking stuff before but didn't really notice a difference in start-up time.

by NewMandrakeUser (not verified)

Will someone please post here when a release date is decided for 3.1 final ?. Thanks !

by Haakon Nilsen (not verified)

According to the release plan at http://developer.kde.org/development-versions/kde-3.1-release-plan.html, 3.1 may be "final" on monday (but binary packages won't be ready until a week after), or if it's found to be not ready, RC3 is released and 3.1 goes final the Monday after (18 Nov). My hunch is that there won't be no RC3 :)

by NewMandrakeUser (not verified)

Thanks a lot Haakon, let's see what they decide next monday :-)

by Nocturno (not verified)


When I compile kmess 0.9.7 with kde3.1 the /usr/bin/meinproc --check --cache index.cache.bz2 ./index.docbook gives me segfault. Anyone knows why (bug?)? (with kde 3.0.3 this not happen)


by Petr Jodas (not verified)

I've the same problem, but I don't know where is mistake. Did you find the mistake? I'm using KDE 3.0.5. With version 3.0.4 everything was OK.

Thanks a lot,

I had the same problem with kde 3.0.5 and fixed it by updating to libxml2-2.4.28 from ftp://xmlsoft.org/.

Good luck !

by Lt_Flash (not verified)

I'm trying to compile KDE 3.4, I have libxml2-2.6.13, and I have segmentation fault on same place...Any ideas?

by Kohn (not verified)

This is a great release. Thank you :)
It feels real stable and polished.

by Curious Windows user (not verified)

I upgraded this system to Win2K and was pleasantly surprised at how muc hbetter it worked that with win98 (despite low memory). It seems to have *much* improved algorithms for swapping and memory use etc. Whne I tried gentoo with all the whistles (preemptive kernel patch etc.) I was very disappointed with KDE3.0.2's speed. Very unsnappy.

Are there any improvements in this situation eminent?

>Are there any improvements in this situation eminent?

yes.. gcc-3.2, glibc-2.2.5 (+freinds) and kde-3.1 compiled from sources with -Os matches w2k response-wise on my old celly500 wiht 128megs if u set them to use equivilent amount of eye-candy. But if u turn on all the flower-power that kde-3.1 has to offer it will of course be less responcive (since it has more then w2k). I have not tried the preemptive patch yet.. but from what i hear it speeds up GIU-response quite a bit :) so maybe i can sqeeze kde to be as fast as w2k even *with* all the gadgetry turned on :)


Remember: cool stuff takes cpu-time.. and RAM.. and disk I/O.. and gfx-ram <-> RAM overhead.

There were definite issues with the speed of kde 3.0.2, but do understand that a poorly compiled kernel can lead to serious slowdowns. Also, the use of imon in the newer gentoo kernels, patch r10 and higher or the lostlogic kernels adds some speed to the whole system for apps that use fam (ala konqueror). KDE 3.1 is faster all around. I was much impressed with the speed increase from kde 3.0.2 to kde 3.1_beta1 which was my upgrade path. Now I'm using gnome 2.1.1 with xft2 and I love it! I'm a kde person, but these new fonts, coupled with how fast gnome is just blows my mind. However, KDE is a better system overall, and might always be that way. Cudos to both development teams! And yes, 3.1 is faster than 3.0.x. and I expect 3.2 to be faster.

heck no. kde 3.1 is even slower. i seem to be getting by ok with a 750mhz duron & 320mb ram.. the jury is still out on that one, though.. i just upgraded my ram from 256mb to 320mb 5-6 hours ago because after a couple days usage my box started swapping to disk (i usually only reboot it when it starts swapping and slows stuff down)..

i have a 1.47ghz pc with 1.5gigs of ram that runs kde 3.0.4, though.. its uptime is usually like 2 weeks or so.. very smooth stable system.. i don't think i've ever resetted it due to a software problem.. certainly never resetted due to any hardware limitations, either.

remember the good 'ol days when coders would optimize their code? ahh.. memories..

by NewMandrakeUser (not verified)

Hey, that sounds like a memory leak. If you can find which application is causing it please report it. It could even be unrelated to KDE (some other app).y Otherwise ... you can restart X from the login manager (KDM). That may (or may not) help you avoid rebooting ...

by Curious Windows user (not verified)

This gives me HOPE! :-)

I think rebooting because of swap must be due to a bug too ... even I know you don't have to do that with Unix and Linux :-) The way to find out is to check if memory use keeps climbing!

On my computer (old) it's slow right from the start and swap is frequent ... But now from these comments it seems with new KDE, Qt, compiler, kernel, patches, linker it may get better!

by Need to take on... (not verified)

It's my impression that there isn't enough bodies and/or time to do real Q/A like leaving KDE up and running for weeks with scripts automagically causing test-cases to run and doign me-profiling.


This has been good sof far but with KDE getting more complex and more big organizations usign it some serious profiling, speed work and deep bug squashing is needed so we get:

- faster start up (launching apps is *painful* even on fast machines)
- stability for long uptimes as a desktop system ... my iBook (which gets *alot* of use) is now on over 5 months uptime (some in sleep mode while transporting etc) with apps up and running in various modes for months at a time and with near *perfect* session management (I log out and log back in to hear my mp3's playing at eactly the same place). This is waht I used to use Unix for since Windows and Apple were relative toyz in the stability department.

It's sad that the situation has actually reversed: both XP and MacOS work much better than in the past while I can't get a new install of Linux/KDE to run sfor more than a few days or a week (as a desktop - server side things are great). I get a crash or lockup of the whole X UI or even the system (to say nothing of individual apps which simply cannot cut it against Outlook or Apple user apps).

Will KDE/Gnome etc ever *stabilize development* long enough for real industrial strength debugging and stability work to be done? This what gave Emacs and apache their legendary stability. It seems now that Unix apps are perpetually *new* and just don't benefit from years of development and debugging that Windows applications do. For this to go back to normal the endless bleeding edgeness of KDE/Gnome must *STOP*. You can't get solid stability if the whole dev. process isn't stable ...

Just some thoughts not meant as a flame.

by Ronald McDonald (not verified)

I agree with your comments completely. Since I've been using NT5, I've had a more stable desktop environment than recent KDE or GNOME versions. Nothing too drastic, but I just don't have the same kind of confidence with KDE as a whole than I do with Windows 2000. They can't be directly compared of course but still, it's a pity.

Ronald McDonald.

by Ookaze (not verified)

It seems you guys have a grave problem, but I don't think it's KDE. The desktop I use here have uptimes of more than 1 month, and it has 3 X sessions running, one with Gnome, one with KDE, and one with XFCE. The X server never got down since I installed Xfree 4.2.1 CVS a long time ago, and Gnome or KDE never got the system or X server down. I don't even stop them when I change the underlying libs (gtk+ or glib or others). Even with so bad treatment, they do not crash, but can start to malfunction ! I compile all my stuff from source, and use gcc 3.2. I think that people which have problems like you are misguided if you think that's the desktops that are not stable enough. The only stability problems I had was with Nautilus crashing every other day (and then it restarts itself immediately :) ). Since I upgraded to gtk+ 2.1.2, it seems to no longer crash...
To sum up, here, stability is perfect, and I never had a problem with launching apps (though it was slow in KDE 2, I don't have any problem since I switched to gcc 3.x, except the early gcc 3.x times )
As my two desktops are so stable that they don't crash on me, I thought all issues were resolved, but as others reported crash, I wonder sometimes if it's not also hardware related, as I should be the less stable of all, compiling all the latest from source...

I'm running KDE on a 450 w/ 128 and I have all of kde built with debug symbols and KDE runs without any problems on my box.... Better than KDE 2 ever did.

by Master Juvenile (not verified)

its enough for doin da basic pc programing buy not good for playing the high intense games

by Paul PARENA van Erk (not verified)

I'm using the Mandrake Cooker RPM's and Licq is acting up. VERY weird. If I set myself away (or N/A or anything else, but online/offline) it gives me the automatic reply dialog, but when I click OK, it won't go away. I have to exit Licq to get rid of it. Also, instead of pressing - once, I have to press it twice to send a msg... ???

by Andreas Zehender (not verified)

I got the same problem after compiling and installing RC2! Maybe some event handling change in Qt caused this.

by chocobo_greens (not verified)

dont use licq :-p SIM is a much better app IMHO...

by Paul PARENA van Erk (not verified)

LOL :)

Sweet, I tried it, it's quite good. Better than Licq IMHO as well now. :) If functions better, looks better... of only it wouldn't have huge linespacing when writing messages and pressing enter. :)

I'm using SIM from now on. Thanks for the tip! :)

by Giovanni (not verified)

Check the attached file...
By the way, clicking on 'Yes' didn't produce satisfactory results :)


The file didn't get attached, so here it is:



by Nigel Stewart (not verified)

That's damned funny! ROTFL!

by Jim Dabell (not verified)

What on earth is the point of saying something like "don't worry about bug x or y, they'll be fixed in the final release"? This is a *release candidate* ffs! Any known bugs should be fixed before making it available, unless it's been decided that they will be put off until the next version.

A release candidate isn't a reminder to fix the showstoppers before final release - that's what alphas and betas are for. A release candidate is what you put out because you think it's ready, and just want to make sure.

by frederic heem (not verified)

I fully agree, there are more than 3500 known bugs to fixed, IMHO, this release candidate is a beta3.

If you wait 'till all known bugs are fixed, you would NEVER release any software. For some small projects maybe, but not for a big project like KDE. face the facts, there will always be bugs.

by Anonymous Coward (not verified)

There is a difference between fixing all known bugs and fixing all the important bugs. 16 grave bugs, 19 major bugs, and a ton of crash bugs ... at least the grave and major bugs shold be considered "showstoppers". They either need to be: tagged as LATER or WONTFIX, downgraded (only if deserved), or resolved. Then and only then should KDE consider releasing 3.1

by Anonymous Coward (not verified)

The KDE project, in its role as a Microsoft wannabe (that wasn't an insult, it was a statement of fact), is going to show itself as guilty of all things from feature creep to style over substance to feature over bugfix release cycles, et al. It is not motivated, nor, some may argue, needs to be motivated, by the strict engineering practices of more critical projects. Users are used to frequent browser crashes, whether Konqueror or Opera or IE or Netscape or Mozilla. Filling in a form with lots of text? Do it in emacs first. Opening lots of windows? Perhaps it's time to fire up Opera so when your system explodes you won't have to search for them all again. This is the current state of desktop software release engineering.

by Jesper Juhl (not verified)

I agree, at the very least there should be a RC3 if bugs are found in RC2.

by Jim Philips (not verified)

In compiling kdebase, configure gave me a warning that I needed libart and libxslt. I downloaded those things and tried a clean configure again. It still said they weren't there. I never did figure out how to make it see them.

And in trying to build kdegraphics, make errored out on libkscan because I didn't have Xsane installed. Fine, I thought, I don't need that program. So, I went back and ran:

./configure --without-kamera --without-kooka --without-libkscan

I could see that, as it configured, it completely ignored these flags. So, when I tried to build again, it errored out. Apparently, there is no way to tell configure that I don't want these packages, despite what ./configure --help says.

by Robin Green (not verified)

<< In compiling kdebase, configure gave me a warning that I needed libart and libxslt. I downloaded those things and tried a clean configure again. It still said they weren't there. I never did figure out how to make it see them. >>

I suspect that you probably installed them with prefix /usr/local and it expects to see them with prefix /usr, or vice-versa.

by dwt (not verified)

Don't forget to remove config.cache

by Jim Philips (not verified)

The problem with configure for kdelibs missing libxslt and libarts is solved. It's a packaging issue. When configure appears to miss a package that you know is installed, you can bet that there is a *-devel version of that package that contains the files configure is looking for. When I installed the devel packages, it quit complaining.

Unfortunately I don't have the time to compile the binaries myself to check this out, but I was told this bug was fixed in the cvs code back when 3.0.2 was out. Has it made it into the build yet? The bug is selecting empty contents on the konqueror location bar does indeed remove the history completions, but exiting konqueror and restarting it restores the history (as if the changes aren't being saved). This of course is highly dangerous because anyone using your browser can see exactly what sites you've been to and there is no way to remove them.