KDE 3.2 Reaches Final Stage: Announcing Release Candidate 1

After over a year of development we're ready to announce the release of the first (and hopefully last) release candidate for KDE 3.2.0. Get it from download.kde.org or use Konstruct if you don't feel like calling configure by yourself. Due to the time constraints, don't expect distribution binaries, but they may pop up at download.kde.org URL too.

Dot Categories: 

Comments

by planetzappa (not verified)

Who the hell is Drantin?

by planetzappa (not verified)

Ah, i see, the poster above... Sounded like some celeb or whatnot. Never mind!

by details (not verified)

it (KDE) is in your hand, your eye, your computer;
marketing is not in CS's mind; they only see "bugs" flying around their heads and codes jamming computers.
if you want details, look inside the source code; if you want detail feeling, catch yourself a mouse.

by Dmitry (not verified)

Well, 3^2+2^2=5^2

So there.

by Cwiiis (not verified)

9 + 4 = 25? :/

by Erik (not verified)

I think maybe you were thinking of the 3/4/5 rule...
It's actually 3^2 + 4^2 = 5^2

by Turd Ferguson (not verified)

I remember reading the release schedule back in mid-2003 and they were shooting for a mid-December release. They changed it, and that's why it's on time.

by Mario (not verified)

Now it's aimed for February release, maybe February 5th ;)

by Giovanni (not verified)

Great release! ;-)
Just a little thing: i can't set anymore the kind of shadow from ~/.config/kdesktoprc
...it doesn't work... and the default is "ugly" :p .
Anyway this is great!!! :-)

by Mario (not verified)

IT better not look this crappy in 3.2 final. We should have a nice MAcOSX, Nautilus, Windows XP style shadow.

by ac (not verified)

Yes, anyone know the story behind the shadow? Why is it so bad? How to fix?

by Bob (not verified)

This shadow thing, what's it all about? Is it good, or is it whack?

by Alex (not verified)

whack. It doesn't even look like a shadow.

by Wilbur (not verified)

The kdesktop icon text shadow was incorporated from a patch originally posted on kde-look.org. Here's the link: http://www.kde-look.org/content/show.php?content=4750

There are parameters that you can tweak to adjust the characteristics of the shadow, and up to KDE 3.2.0_beta2 they were located in ~/.kde3.2/share/config/kdesktoprc.

Since I installed KDE 3.2.0-rc1, changing the parameters don't seem to work anymore. Can anyone post the contents of their kdesktoprc file?

by Navindra Umanee (not verified)

I've been running HEAD since Saturday evening and so far it's fantastic. All the glitches I had from the previous version are gone. I see a lot of polish and I definitely see speed improvements. I doubt another RC is needed.

That default gray/gears background isn't very good IMHO. Not only is it drab, it's harsh. Also the default desktop font shadow isn't anywhere good as the Nautilus desktop shadow. I'm not sure if this can be tweaked or not. I also think we should probably default to the Bitstream Vera fonts everywhere. Oh yeah, and Konsole should default to Linux Colors. :-)

The Dot frontpage looks like it lost some whitespace in Konqueror. There's very little space at all between the "comment number" line and the title of the next item. There should be a

. Otherwise, Konqueror seems fantastic and all my other bugs are gone.

More serious gripe: Cut'n'paste glitches sometimes when selecting in Konsole and pasting in Konqueror it doesn't quite work... behavior seems random -- rare but it happens. Also KDE stole my Control-A (beginning-of-line) for no good reason at all since it doesn't work. Ctl-A selects the whole text and yet does not put it in the paste selection even after pressing Ctl-C (does not paste with Middle Button nor Ctl-V). That's it for bugs, but I think this one is the most serious and annoying.

Otherwise, I'm a real happy camper and I want to see this release adopted widely ASAP. :-)

by Thorsten Schnebeck (not verified)

Have you tried to start after prelinking kde?
I also made a clean install in a new /usr/kde/3.2 dir and after prelinking I could not start kde. There were kdeinit startup problems and lost dcop communication. Startup crashed at 28%.

My test was done with HEAD and qt-copy not with 3.2_BRANCH.

Bye

Thorsten

by Navindra Umanee (not verified)

I didn't do anything special like that. What do I need to do to prelink my KDE? (I'm on Mandrake 9.2)

by Thorsten Schnebeck (not verified)

Here is Gentoos Prelinking Howto, should be valid for Mandrake, too.
If you use NVidias binary driver you have to compile Qt with the (new)
-dlopen-opengl configure option (I *think* this option is qt-copy only, so far)

http://www.gentoo.org/doc/en/prelink-howto.xml

+++
3. Prelinking - Prelink Usage

I use the following command to prelink all the binaries in the directories given by /etc/prelink.conf.

# prelink -afmR

Warning: It has been observed that if you are low on disk space and you prelink your entire system then there is a possibility that your binaries may be truncated. The result being a b0rked system. Use the file or readelf command to check the state of a binary file. Alternatively, check the amount of free space on your harddrive ahead of time with df -h.

The options explained:
-a "All": prelinks all the binaries

-f Force prelink to re-prelink already prelinked binaries. This is needed as prelink aborts if old prelinked files are present and their library dependencies have changed.

-m Conserve the virtual memory space. This is needed if you have a lot of libraries that need to be prelinked.

-R Random -- randomize the address ordering, this enhances security against buffer overflows.

Note: For more options and details see man prelink.
+++

Bye

Thorsten

by rsk (not verified)

Doesn't mandrake already prelink their binaries? I thought they did (like Redhat) which caused the great load times...

by bugix (not verified)

"I also think we should probably default to the Bitstream Vera fonts everywhere."

Yup, they got added in XFree 4.4 so that would be a nice default.

by Alex (not verified)

I agree with everything you said except the wallpaper and konsole statement. Can't wait for KDE 3.2 on February 5 (3+2=5) Please release it on the 5th.

by kormoc (not verified)

How about Feb 3ed? (03/02/04) for kde 3.2? :)

by William (not verified)

all is in the title

by Mario (not verified)

Right now it seems that KDE 3.2 is just too buggy, I think it should have a RC2 and have a mid February release date, otherwise I will consider it a rushed product.

Check the statistics for yourself, sure bug counts aren't all tat important, but when this late in the release cycle there is such a huge spike in new and unconfirmed bugs, you know there is something wrong. Besides, the goal for 3.2 was to have a release with under 3,000 (2,500 was planned) bugs, now it seems the new goal is under 4,000.

Bug chart here http://tinylink.com/?OdDme9ObFk

Notice how last year for KDE 3.1 the number of unconfirme dbugs and new bugs went straight down as if freefalling, this is how it should look for 3.2, but instead it shows a large increase in bugs, not a decrease as is normal.

I want KDE 3.2 to rock and right now on my system it just isn't where is should be a this stage in the cycle. To make KDE rock it needs at least one more RC. From what I've done on software development I know that the RC should be released when you think everything is the way you want it to, because when you think everything is like you want it to be, you will notice in the RC, that it's not quite there yet mos tof the time. But sometimes, like for Linux kernels, the RC becomes final because it really is where it should be.

Thank you, please consider a RC2 for a good 2-3 weeks more.

by JC (not verified)

Did you tried RC1 ?
It's stable, no crash of konqueror or others apps.

All my bugs from beta2 are gone. But they still open in the bug database. Probably duplicates or somebody didn't closed them. There are many reasons why there are many opend bugs.

But the current rc1 is ready for primetime

by Carlo (not verified)

>But the current rc1 is ready for primetime
Sure? Is e.g. this showstopper ( http://bugs.kde.org/show_bug.cgi?id=70070 ) fixed in rc1?

by anonymous (not verified)

Your bug is neither confirmed nor marked as critical. So I guess the developers have a hard time to reproduce it.

Also I'm pretty sure that they need more information from you like your language and locale settings.

by Carlo (not verified)

1) It's not a locale problem.
2) The involved devs speak german, but even if not, everyone should be able to translate JJJJ to YYYY in this context.
3) It doesn't matter, if the bug is marked critical or not, if the user experience sucks.

by cloose (not verified)

> 1) It's not a locale problem.

But it seems to be at least a local problem since I never experienced anything like this. So the developer surely does need more information from you about your setup.

> 2) The involved devs speak german, but even if not, everyone should be able to translate JJJJ to YYYY in this context.

Of course but that's not what I meant. Talked about your language and locale _settings_.

> 3) It doesn't matter, if the bug is marked critical or not, if the user experience sucks.

I'm sure it sucks. I'm also sure that the developer works on this as fast as possible, but you were talking about a _showstopper_ that should delay the release. IMHO this is not the case.

by Carlo (not verified)

>But it seems to be at least a local problem since I never experienced anything like this.
Play around in KOrganizer, setting the month and years a few decades forth and back, open the print dialog and you should be able to share the problem.

> Talked about your language and locale _settings_.
Still wondering what it could have to do with it.

>[...]but you were talking about a _showstopper_ that should delay the release. IMHO this is not the case.

_showstopper_ not from the technical standpoint (it's a trivial bug, rm -rf ~\.kde and i'll get the date shown again - I hope so at least), but from the user standpoint it simply sucks. Think about opening kicker->clock->calendar and watching the date 01.DD.YYYY, searching for an email by date and all of them are formatted like this...

I could mention other things. Freezing kde, when noatun opens empty or broken audio files, lost settings of open kde applications, on next restart after kde had to be killed, ...

by Carlo (not verified)

~/.kde of course ;)

by anon (not verified)

please list the bug numbers..

by John van Spaandonk (not verified)

I think that the following bugs should be solved before 3.2

CRASH: Bug 72775: CRASH: printing message in draftfolder

Bug 70418: [test case] table height=100% gives strange gaps (regression)

(this one prevents me from using the web interface of my company's
Novell email system68921

Bug 68921: Marking text with keyboard disables keyboard input )

This one makes it very hard to edit something in a box on a web page.

I could go on...

For example there are quite a few webpages where the javascript does
not work or even whole javascript menus do not show up.
Mail me (see the bugs for my email address) if you need examples.

by James Richard Tyrer (not verified)

> no crash of konqueror or others apps

Konqueror crashes for me.

I have filed several other bug report for the branch.

Yes, it still needs a little work.

--
JRT

by Anonymous (not verified)

> I think it should have a RC2 and have a mid February release date

Another RC would be not about greatly reducing the amount of bugs. In fact only showstopper bugs are allowed to be fixed now in KDE_3_2_BRANCH until release.

> otherwise I will consider it a rushed product.

Silly, it's already delayed by almost two months.

> but when this late in the release cycle there is such a huge spike in new and unconfirmed bugs, you know there is something wrong

Sure, users delaying their reporting of bugs they know since Beta1/Beta2 until one week before release.

> Notice how last year for KDE 3.1 the number of unconfirme dbugs and new bugs went straight down as if freefalling

That was the time when the bug system was switched and many duplicates and old bugs were closed. Did you also notice how until the release of KDE 3.1 in January 2003 it almost climbed up back again?

> To make KDE rock it needs at least one more RC.

No, it needs KDE 3.2.1, 3.2.2, 3.2.3, ...

> the RC should be released when you think everything is the way you want it to

Then we would see never see a release.

by Source (not verified)

> > To make KDE rock it needs at least one more RC.
> No, it needs KDE 3.2.1, 3.2.2, 3.2.3, ...

Exactly,
- To buggy to be released as stable. Too many minor bugs and annoying issues.
- Will only be stable enough after the release . It needs time and actual use to mature.

IMO the obvious solution is quite simple actually.
Keep the process, change the names. The 1st release (with binaries and all), after the short sequence of RCs should still be called a RC and not a .0 version. It would have a lifetime of 1-2 months and then the equivalent to .1 would be the .0 release.

by anonymous (not verified)

This won't work. Fact is most people don't even test RCs (ask Linus).

by Source (not verified)

Yes it will. Fact is most people do (ask the Mplayer team).

by jts (not verified)

People are way more likely to use the RC's for something like Mplayer then for something like KDE or a kernel. The reason? What is the worst thing that happens if Mplayer doesn't work right? You can't watch videos, big deal.

If your kernel has major issues, or the system of which you most often use to interface with your computer has major issues, it is a lot bigger deal. There is a reason why the kernel is never ready in a .0 release and that is because the user base of a kernel goes up by a factor of 10 or more as soon as they make a .0 release. Why do you think every kernel has a rush of bug fixes at the begining and it settles out as time goes on and there are a lot fewer releases.

by Source (not verified)

"People are way more likely to use the RC's for something like Mplayer then for something like KDE or a kernel. The reason? What is the worst thing that happens if Mplayer doesn't work right? You can't watch videos, big deal."

I know that. I was beeing sarcastic.
They're more likely to use Mplayer than KDE, just like they're more likely to use KDE than the kernel. I was just using his distorted reasoning.

by Jan Ekholm (not verified)

MPlayer has never had a stable release in their whole project lifecycle. So, yes, if people want to run MPlayer at all they are forced to run one of the eternal "release candidates".

by oliv (not verified)

This is completely wrong!

Please do not confuse stable and numbered 1.0. The 0.90 was stable. Only bugfixes/minor enhancement were done to the serie, while there was a development branch aside (called "main").

Just having add a look at Mplayer's news archive page would have given you facts instead of attacking Mplayer with blatant mistakes (or was is a lie?)

For example the annoucement for 0.90:

" 2003.04.06, Sunday :: Finally! MPlayer 0.90 released!
posted by Gabucino
459 days have passed since we released our last "stable" release: MPlayer 0.60 "The RTFMCounter"."

by Stephan Kulow (not verified)

You're aware that your "bug charts" contain feature requests, aren't you?

by Moe (not verified)

I use kde 3.2 10 hours a day 5 days a week for heavy development and it is more stable/efficient than kde3.1, gnome-2.4 or WindowsXP ever since beta1.

-> No crashes
-> lisa, fish, smb are seamless now
-> konqueror is very fast
-> KDE 3.2 now loads faster than winXP and gnome.

I know several people that I work with have had great experiences with it so far. If you are having problems check your cflags, glibc and gcc versions or report a bug. Unfortunately many people who mean to help be reporting bugs inadverntantly submit user errors as opposed to actual bugs. It is usually a bad idea to base the stability of an app based on the number of reported bugs.

One good explanation for the increase in bugs in the increase in user base, particuarly newbies ;) We can only hope...

by Mario (not verified)

=p

by Janne (not verified)

"but when this late in the release cycle there is such a huge spike in new and unconfirmed bugs, you know there is something wrong."

What makes you say that? Let me guess: Since there was a spike in number of bug-reports, you automatically assume that it means that there are more bugs, right? Well, it hasn't occured to you that the spike may be due to:

a) There were more users reporting bugs
b) Those bugs had been there for a long time already, but they were just now being discovered
c) due to part a), there were lots of dublicates
d) Due to having more users, there were more wishes (wishes are reported in bug-reports as well)

None of those are bad. Just because number of bug-reports go up does NOT mean that the code is magically becoming buggier. It just means that more people are reporting more bugs.

If I release some app, and to my knowledge it has zero bugs. After two weeks, I have received 20 bug-reports. During those two weeks I haven't touched the code at all. According to your logic, my code would have somehow magically transformed to contain those 20 bugs, when in reality they were there all the time, I just hadn't noticed them.

If you run KDE today, and next week there are (for example) 100 new bugs being reported, it does NOT mean that the KDE on your hard-drive has somehow magically become more buggier.

To my knowledge, Mozilla has over 10.000 reported bugs, and that's just for one app!

by anonanon (not verified)

> To my knowledge, Mozilla has over 10.000 reported bugs, and that's just for one app!

it had more than 100,000 last time i checked, which was over a year ago

by Anonymous (not verified)

Perhaps the version numbers should be determined objectively =P

e.g. version = target version - ceil ( (bugs opened - bugs closed) / n ) + c

by Adrian (not verified)

You would expect an increase in bug reports when a project moves from beta to RC status simply because more users will try it at that stage. Similarly, I'd expect another spike in bug reports when it goes from RC to final. I'm not saying you're wrong about RC1 not being ready though - just arguing with your point about more bug reports implying something has gone wrong.
But even 3.2.0 will probably not be a totally satisfying end-user product, just because until it's had a lot more hammering there will still be bugs to work through. It'll really start to get that hammering when 3.2.0 is out and more people try it (hopefully debian/unstable will have it pretty quickly).