I installed the SuSE binary packages - other than having to use nodeps to keep the kdebase3-SuSE package installed, it worked.

Two issues:
- Why the stupid shadow font for the desktop icons? Worse, I can't seem to find a way to change it (no appearance on "Configure Desktop" and the control panel setting for desktop font doesn't let me turn off shadow)
- The control panel is buried several several menus down - Why?

Look if you cant do these things, then you shouldn't be downloading raw kde. go and buy lycoris or lindows. its got this already nicely arranged for you. These guys working here are volunteers. not tech support.

I just upgraded by Gentoo to KDE 3.2 (10 hours of compiling, whoopee!) and had the same problem trying to find how to remove the shadow. I would not say placing it in advanced options under background was obvious at all.

I would expect it under Control Center -> Desktop -> Behavior and was checking all the appearance options for a long time until a stumbled on this post.

Ps. I'm trying to get off XMMS to something more KDE integrated, I've been using amaroK but KDE3.2's install seemed to have wiped that, not liking JuK so far, what do you like for playing mp3s?

I saw nothing there that warranted being rude. Advanced Options isn't at all obvious, and if you think it is, and you volunteered your time to put it there, maybe you shouldn't be volunteering your time to put it there.

I'm new to SuSE, so let me ask a dumb question: can I expect to see KDE 3.2 turn up in YaST Online Update, or do I need to install these tarballs manually? I played around with the Beta and RC1 tarballs, but they had multiple dependancy conflicts, and SuSE integration (things like susewatcher) stopped working-- it was all pretty disappointing.

Yeah, I noticed this in the README on the FTP mirrors. Is there an ETA on when 9.1 will be released? If it is going to be later than next month, I can't wait that long... I don't really remember them doing this before--are they going to use new releases to string us along? Guess it's time to look at Konstruct.

SuSE have brought out around 3 releases per year for some time now. The last release was at the end of September, which is 4 months ago. They like to include such major releases of KDE in their releases - other releases have come out following KDE releases.

It would not surprise me if we see 9.1 out this month, including KDE 3.2 and kernel 2.6.1. At least, I'm hoping they bring it out soon as I'd like to buy a copy!!

In the mean time, I download the RPMs and install by hand. I like to get the source RPMs and rebuild for i686, but often the build bombs out. Strange, huh?

IANA Suse Employee however, not YOU but KDE download, and eventually a new distro (one way of giving something back...) and as for screwing things up with betas and RCs - do it regularly myself - but I've always thought that was my problem.

The instructions at these pages are very unclear. In deban (e.g. at apt-get.org), when someone announces a new repository, they list the full repository line as it appears in the sources list. The suse apt site doesnt seem to do this anywhere. Could you please post the full sources.list lines required for this upgrade?

Ah, yes -- that was a fun afternoon. I use Debian on my old powerbook, so I had already encountered the charms of apt, but didn't know it existed for SUSE, too. A bit slow though -- does anyone know of a mirror in the Netherlands? And... It insists on installing qt-3.3.0, which is giving me a hard time picking up Krita development again. But it still was fun. Thanks for the tip!.

The reason for the fast turn around time was the failure to fix some of the serious bugs in RC1 and issue another RC (which would have been RC3).

Please see bugs #73379 and #73851 for examples. Actually, I was surprised that such serious bugs had not been fixed in the Betas.

I should try to make this clear since I have already been flamed for this on the 'kde-devel' list. I am interested in a high quality product. I believe that a commitment to excellence must come first. It has become obvious that there are a significant number of developers that lack this commitment.

Please get with the program!

As another user posted: Quality Management -- a Commitment to Excellence!

The first step in instituting a Quality Management program is to have a Quality Assurance team. For that we need volunteers. This could work if we have a lot of volunteers that only do a little. Specifically, if you report a bug and can keep an up to date copy of the CVS for the pending release, you can check to see if the bug gets fixed before the release. Of course, this won't do any good if the developers simply ignore the bug and release any way. A list of the critical bugs must be prepared and the release must be delayed until they are fixed and "signed off" by the QA team.

We need testers, to report bugs, that will install, preferably built from source from CVS, a copy of RC1 and risk using it as their regular desktop because it is only by using it as your regular desktop that you will find the bugs. You will need to update to new RCs when they are tagged. And, you will need to change the tag to RELEASE when it is added and update it every day, report bugs, and check on the bugs that you have reported.

We also need people to confirm new bugs and test old bugs to see if they have been fixed. It would be best if you had an up to date copy of the CVS for the current BRANCH. The reason such help is needed is that IIUC, many developers do not keep a copy of the current release BRANCH and are testing bugs only on HEAD -- not a good idea. Specifically, they should first be tested on the current release BRANCH to see if they are currently valid. Then, they can be tested on HEAD to see if they are being fixed. However, bugs that are valid on the current release BRANCH and which have been fixed on HEAD should not be considered closed until they are confirmed fixed in the next release. That is what Quality Assurance is all about.

Without your help, we will continue to have buggy releases like KDE-3.2.0

"Magoo's inability to distinguish between his nephew, wearing a raccoon coat, and a wild bear, combined with his pig-headed refusal to consider the possibility that his sight might be failing, made a big hit with audiences.."

Software has bugs. There is no process that will make bug free software. Especially with something incomplete, like KDE.

So we will have a 3.2.1, etc. Some bugs will be fixed in those releases, some won't because of string changes, or design changes required to fix them. They will be done later, maybe 3.3, maybe later again.

If the release date was put off further, there would be an even greater gulf between what the developers are working on, and the release tree. Yes, developers generally get on with new stuff, features, finishing things up. The release dude can only suggest what people work on.

Yes it seems chaotic. But it works at least as well or even better than any other system. Even the tightly controlled processes that NASA uses didn't get everything right. But trying to impose tight control over this project will imho, cause harm.

Yes of course it has. But some bugs are just too grave to justify the RC or Release title. For example, in RC1, just drag a file to a konqueror window and it crashes. Such obvious bugs don't belong in a RC release.

A few months ago, I thought of doing a bug of the week sort of thing for the Digest. So on #kde-devel I mentioned a few of the obvious ones. The responses to each bug was an explanation of the issue. The problem had been investigated. The fixes often require major rewrites, adding new technology or capabilities, or as Waldo mentions, depends on someone else's libraries. Should the release be delayed? Till when? No. Release now. There are major improvements in 3.2. There is still much work to do.

The fact that it is a regression makes it more serious that it would be otherwise. And comparison with other software should also be considered when determining how serious it is.

That is, it works correctly in Mozilla and it works correctly in Konqueror 3.1.5. These two facts make it a more serious bug than if it were taken in isolation.

Although bugs (design issues) are to be expected in new features, when there is a regression which is clearly a coding error in mature sections of the code it is a greater issue. Consider what is going to happen, a user upgrades from 3.1.5 to 3.2.0 and something that worked fine in 3.1.5 suddenly stops working. Most users don't like that.

OTOH, consider a new feature (especially if it can be turned off) if it doesn't quite work yet, no big deal.

I disagree.
Tabs are useful when you're browsing different sites at the same time, because they allow you to have many sites open concurrently with little desktop real estate overhead.
Pop-ups are NOT the same thing at all. Pop-ups work as additional information (password entry, movies window...) on the CURRENT site; you can't stash them away for later browsing like you do for a new site or page.

The current Konqueror behavior is a usability bug. I fear that if we don't fix it, people will switch back to other browsers that behave the way they expect.

I've just voted for the bug, too, since it's indeed a bit of a wart that should get fixed.

I agree, I personally love the new behavior and can't imagine that someone is seriously advocating popup windows. I usually consider the utilization of popup window as bad behavior which should be avoided whenever possible, may it be on website or in applications.

What I can say is that until somebody figurers out how to display two tabs at once that I don't find it a feature. Specifically when using an online catalog and the pop-up window is a larger view of the item.

Also, this behavior can lead to errors because the new tab is a fully functional browser window.

It seems to me that this release should have been named
"beta" or "release candidate". It contains many oops's which are definitely due to hasty package preparation and lack of serious testing. Just two examples.
First, some .h.in files in subdirs of kdelibs package (e.g., dcop-path.h.in) are older then configure.in in kdelibs root directory. As a result, make tries to run autoheader. If autoconf is absent or is old enough (like 2.13), autoheader will fail, leaving config.h.in empty and newer then config.h. If you rerun make, config.h will become empty. So, if you run make just once, everything seems to be fine. But if you happen to hit some compilation error (more on that later), you are out of luck.
Second, kdefx/kstyle.cpp in kdelibs contains ifdef check for Qt 3.30. If Qt has this version, it adds additional cases in the switch statement for PM_MenuBarItemSpacing. I have Qt 3.30b1 installed. It defines QT_VERSION 0x030300, but does not have PM_MenuBarItemSpacing anywhere in it's source.
Now, take those two bugs together and...
May be I'm wrong and had done something stupid myself, but such things do not invest into KDE's popularity. Wasn't it better to allow more RC's just to stamp out such bugs?
Sincerely, Igor Romanenko

1. Ok, to be more specific: I was talking about compiling kdelibs SOURCE PACKAGE released yesterday (kdelibs-3.2.0.tar.bz2). Or why would i talk about such things as autoconf and autoheader?
2. Library requirements say Qt >= 3.2.3. So, either requirements page is wrong or my configuration is supported.