KDE 3.5 Release Candidate 1

KDE 3.5 is almost finished, so we have prepared a first release candidate. We want to have it tested as much as possible, so please give it a show. You can download the sources from To compile them you can use the Konstruct build script . In the short time frame since tarball creation only binary packages for SUSE Linux got finished, Kubuntu are uploading theirs. Thanks for your help in reporting bugs and giving feedback so far. Update: There is now also a Klax Live-CD for this release available.


This time I want to help out but I'd like to know whether I can get back to my good old KDE 3.4.3 when things do not work out with the KDE 3.5 rc1. I have 1 machine and a single hard disk. I am running Kubuntu Breezy and have done lots of customizations done. If this is not possible, what can I do to mitigate the mess I might find myself in, in case I take the plunge?

By This time I wan... at Sat, 2005/11/12 - 6:00am

I did install beta2 and it was too buggy for me so I downgraded to 3.4.x. This is how I did it:

apt-get remove libarts1c2 kubuntu-desktop

removed beta2 lines from sources.list

apt-get install kubuntu-desktop

and it worked

By patcito at Sat, 2005/11/12 - 6:00am

There are two ways to be safe:

1) Backup your important data;

2) Stick to official Kubuntu packages.

By Reply at Sat, 2005/11/12 - 6:00am

If you want to be sure you have to use a virtual machine where you set up a second Linux but with KDE 3.5, or you have to install KDE 3.5 only local, which is possible when you use konstruct or kdesvn-build.

I personally had nice experiences with konstruct:

But after that I tried kdesvn-build, and that was even better:



By Roland Wolters at Sat, 2005/11/12 - 6:00am

With kubuntu you can use the package debootstrap to install KDE3.5 and keeping KDE3.4.3

By Cyrille Berger at Sat, 2005/11/12 - 6:00am

I just use kontruct, but let it install to another diretory, eg /opt/kde3.5rc1.
For my testing I use a fresh account, so the customizations and data of my 'normal' account don't get messed up.

If all runs well and I decide to use the new version day-to-day, I rename .kde in my 'normal' users home, then log in the new kde-version and copy back the data (bookmarks, etc.).


By Alfred at Sat, 2005/11/12 - 6:00am

There will be the Live Klax ISO to test it?

If yes, is there a (possibly simple) way to boot an ISO from HD, without burning it to CD/DVD?


By Alessandro at Sat, 2005/11/12 - 6:00am

to my knowledge there is currently no such way.

if its about the cost/waste than a cd-rw help out nice for the live iso testing.


By cies breijs at Sat, 2005/11/12 - 6:00am

The trouble is that my notebook can only read CD/DVDs, but not write them :-(

By Alessandro at Wed, 2005/11/16 - 6:00am

Vmplayer can do that, if in a non-free way.

There are guide around on how to change the browser-thing to any OS you want, including live cds (I have a knoppix vm image on my disk atm :P)

By Narg at Sat, 2005/11/12 - 6:00am

Thanks, but I need a copy of vmware to create the vm to launch with vmplayer, is it right?

By Alessandro at Wed, 2005/11/16 - 6:00am

Check out QEMU. Homepage:
Your distro probably packages it. Start the cdrom with:

qemu -cdrom cd_image_file.iso -boot d

man qemu for more information :)

By Anonymous Coward at Sat, 2005/11/12 - 6:00am

Thanks, I'll try this!
It seems promising...

By Alessandro at Wed, 2005/11/16 - 6:00am

It seems the Live CD is now available.

By Anonymous at Sun, 2005/11/13 - 6:00am

Yes, you are right.

By Alessandro at Wed, 2005/11/16 - 6:00am

What I'm looking for, is a way to boot from an ISO like you boot from a partition with GRUB, Lilo, Smart Boot Manager or others.
Something like LOADLIN could be nice too.

Advantages are:
- you don't have to burn the CD/DVD
- you can use it without a CD/DVD burner and even without a CD/DVD reader!
- reading from HD is much faster than reading from CD or DVD.

Thanks for every answer.

By Alessandro at Wed, 2005/11/16 - 6:00am

As long as slave forwarding doesnt work.

Try opening a .tar.bz2 in media:/whatever. It doesnt work.

Or is it planned for KDE4 only?

By PT at Sat, 2005/11/12 - 6:00am

Gosh, you're correct, this is really an issue since IOSlaves are going to be the default to navigate through your file system in KDE 3.5 (think of home:/). There is definitely the problem of appending one IOS to another, and the new default will lead to lots of complains, I bet.

By Davide Ferrari at Sat, 2005/11/12 - 6:00am

this still doesn't work? i thought it got fixed... at least you can now burn cd's from media:/ directly with k3b...

By superstoned at Sat, 2005/11/12 - 6:00am

Not exactly the same, this is about using ioslaves in media:/. If you have Ark installed it will handle the compressed file seamlessly, but kio_tar etc will not.

Personally I think the concept of the whole system:/ and media:/ thing are broken, the k3b issues demonstrated it nicely. Inconsistencies keep popping up all over the place requiring constant fiddling with the implementation. And even if you neglect the inconsistency issues, the end result still does not improve usability very much. Which was the whole purpose of the thing.

By Morty at Sat, 2005/11/12 - 6:00am

Well, IMO the idea of abstracting from the regular Unix filesystem is a great one, don't get me wrong, but while Kevin put a lot of effort into it. it's something that has should be postponed for's quite a radical change and as you said the process it's leaving quite a few inconsistencies (being the KIOs append issue one of the most noticeble).
IMO now in RC1 time is even too late to step back, it will lead to even worst problems IMO, so let's hope in the 3.5.x series for some bugfixes and definitely to KDE4 for a major revamp.

By Davide Ferrari at Mon, 2005/11/14 - 6:00am

Yeah, the implementation needs a lot of work. In its current state, it is a huge step backwards from standard paths. For example, take this common task (I just ran into this yesterday)

In kubuntu, plug in a Digital camera, and the media://camera pops up in konqueror. So far so good. Now I want to send a picture to a contact on MSN through Kopete. So logically I go Send file - navigate to the media://camera directory, and choose my picture. But then kopete says that I cannot choose remote files to send. Huh? Remote files? It's on my camera! Now I know enough to copy the pics to the hard drive first, but a normal user would be stumped at this point. I really don't understand why we can't let the distro mount the camera under /media/camera or whatever and open that dir in konqueror when a camera is plugged in. Would make everything much more consistant.

By Leo at Tue, 2005/11/15 - 6:00am

Another example;

If I put a movie-dvd in the player, it's mounted and shown as media:/hdc, in the media:/-view it's impossible to view the dvd-content (files) in Konqueror, I need to manually go to the mount-path in Konqueror, to be honest this is quite annoying.

By LB at Tue, 2005/11/15 - 6:00am

"it is a huge step backwards from standard paths."

"I really don't understand why we can't let the distro mount the camera under /media/camera or whatever and open that dir in konqueror when a camera is plugged in. Would make everything much more consistant."

"in the media:/-view it's impossible to view the dvd-content (files) in Konqueror. to be honest this is quite annoying."

I can't say anything other than I agree with Leo and LB, the only thing actually achieved by trying to abstract the regular Unix paths with this are making everything less consistent. And having to do lots of work hunting all the different kind of use cases and make them work. And rather than creating better usability, it only creates a inconsistent mess. Introducing another naming scheme for the users to learn. And it's at best only marginally better usability wise, and even useless for legacy applications. IMHO the whole idea should have undergone a real usability review, with lots of why's asked.

By Morty at Wed, 2005/11/16 - 6:00am

This is because kopete is detecting the media:// as a remote protocol just like http:// in a web browser. And therefore its upto kopete to modify its code to allow this as a local protocol. The other option would be to take you back to the standard path, but it's more about time to get the new system running consistently with other apps.

By Ewan Marshall at Mon, 2005/11/28 - 6:00am

Is there already a bug report for this? If yes, can you give the number. (Thank you!)

Have a nice day!

By Nicolas Goutte at Sat, 2005/11/12 - 6:00am

By Michael Jahn at Sat, 2005/11/12 - 6:00am

Bug #73821 is more general and can probably not be implemented in KDE3.

But media: often handles local files and so they should be given to a tar: (or zip:) KIO slave.

Have a nice day!

By Nicolas Goutte at Sat, 2005/11/12 - 6:00am

I reported it in august:
(or bug:110951 for the ALT+F2 lovers out there).

And its not even confirmed yet.
Was I too vague in the bug description?

By PT at Tue, 2005/11/15 - 6:00am

huh. Zero problems with that here. I can go to media:/sdb1 or whatever and open all the zip, tar.gz or tar.bz2 files I want. (this in KDE 3.4.2). Is there some more specific case you can give me that should fail?

By jason at Sat, 2005/11/12 - 6:00am

Maybe you should try using the release that is supposed to be broken, ie KDE 3.5, instead of a completely different version?

By kundor at Mon, 2005/11/14 - 6:00am

can't find it anywhere (though it's available for Suse 10.0) and kdelibs3-devel-3.5.0-2 is dependent on it.

Any ideas? Anyone else experiencing same?

By Bill at Sat, 2005/11/12 - 6:00am

You can ignore this wrong dependency (--nodeps).

By Anonymous at Sat, 2005/11/12 - 6:00am

I've been using KDE 3.5beta1 and beta2 as soon as they were out and to me they are just as rock solid as KDE 3.4.2 the last 3.4 I've been using. I think 3.5rc1 must be even more polished, and must have some other niceties worth upgrading.

By Me at Sat, 2005/11/12 - 6:00am

KDE 3.5 went into feature-freeze before Beta 2 so RC 1 will hardly have new niceties.

By Anonymous at Sat, 2005/11/12 - 6:00am

but it's sill possible. The new style for Kopete was commited because it is like data file, not a new feature in c++.

By Johann Ollivier... at Sat, 2005/11/12 - 6:00am

Intrestingly the Ikons of left to the Kopete window show the problems of the current Icon scheme. they depict 3 dimensional objects with different angles.

By Andre at Sun, 2005/11/13 - 6:00am

If any klik:/ packages would be made available for testting that would probably make it very easy for a lot of people to give it a shot while not affecting their current desktop.

By bsander at Sat, 2005/11/12 - 6:00am

Is there a standard way to install kde 3.5 RC1 on Suse ? I'd prefer to add a source to Yast and then update rather than playing directly with rpm. Thanks.

By Med at Sat, 2005/11/12 - 6:00am

I checked the ftp-site, but did not find any yast-specific directories/files on it.
So you can't use the ftp directory as yast source.
But you can try to do the following:

1 - download all files to a local directory, then right click on that directory and select [Actions->add directory as yast source] (or similar option)

2 - download all files to a local directory, open a konsole, go to that directory and type "kdesu "/sbin/yast2 -i *.rpm"

By rinse at Sat, 2005/11/12 - 6:00am

Thank you very much, option 1 worked perfectly. However now the graphical login screen doesn't work anymore. I guess it has something to do with kdm. Any idea ? Thanks.

By Med at Sat, 2005/11/12 - 6:00am

> Is there a standard way to install kde 3.5 RC1 on Suse ?

Try adding their KDE yast-sources from the supplementary folder.

This source should be updated with new KDE packages, don't forget to "refresh" the source to see the updated packages. Now open the "Yast software installation", make sure you see all packages in the "Installation overview" (by enabling the "Keep" option). Right click on the package list, choose "Upgrade when new version available".

It's somewhat a hack, but it works if you want to upgrade packages :-p

By Diederik van de... at Sat, 2005/11/12 - 6:00am


I used konstruct last week to build and test KDE 3.5b2.

Among other things, I was obliged to update akode to "akode-2.0b3.tar.gz", (instead of beta 2), to add directly forward declarations into some tarballs downloaded by konstruct (because of gcc 4.0.2 delivered into my mandriva), and so on ...

now "svn up" refuses to update my "konstruct" directory. I do not want to rebuild everything, but only tarball that have been updated between beta2 and RC1.

Do you have a tip to handle this simply (other than having to restore everything manually) ?


By Tmor at Sat, 2005/11/12 - 6:00am

i'm just dreaming of downloading 3.5.0 from official debian unstable repository after no more than a weak since the release...

hope that there wont be any more abi transitions or release freezes...

By Nick at Sat, 2005/11/12 - 6:00am

I second that...

By Stackbit at Sat, 2005/11/12 - 6:00am

I third that... :)

By Petteri at Sat, 2005/11/12 - 6:00am

as do i !! especially since debian and kde are supposed to have such a big cooperation agreement...

By tellico at Sun, 2005/11/13 - 6:00am

so do I, I could really not wait and compiled all with konstruct today.
Worked well, will now find a way to integrate my compiled build into sid,
and the day 3.5 has been uploaded, I'm gonna simply reinstall (over) it

By ac at Sat, 2005/11/12 - 6:00am

cool... great...

i'm looking forward to really seeing KDE 3.5!

By barosl at Sat, 2005/11/12 - 6:00am

I just tried to compile KDE 3.5 rc1 from source but I get an error with kdeutils:
make[3]: Entering directory `/multimedia2/src/kdeutils-3.5.0/superkaramba/src'
if g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/kde/include -I/usr/lib/qt/include -I/usr/X11R6/include -I/usr/local/include -I/usr/local/include/xmms -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/include/python2.4 -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -MT meter_python.o -MD -MP -MF ".deps/meter_python.Tpo" -c -o meter_python.o meter_python.cpp; \
then mv -f ".deps/meter_python.Tpo" ".deps/meter_python.Po"; else rm -f ".deps/meter_python.Tpo"; exit 1; fi
meter_python.cpp: Dans function « PyObject* QString2PyString(QString) »:
meter_python.cpp:129: error: cannot convert `Py_UNICODE*' to `const wchar_t*'
for argument `1' to `PyObject* PyUnicodeUCS2_FromWideChar(const wchar_t*,
make[3]: *** [meter_python.o] Erreur 1
make[3]: Leaving directory `/multimedia2/src/kdeutils-3.5.0/superkaramba/src'
make[2]: *** [all-recursive] Erreur 1
make[2]: Leaving directory `/multimedia2/src/kdeutils-3.5.0/superkaramba'
make[1]: *** [all-recursive] Erreur 1
make[1]: Leaving directory `/multimedia2/src/kdeutils-3.5.0'
make: *** [all] Erreur 2

I've searched in kde bug tracking system and found nothing, maybe I've done something wrong, or maybe should I add a bug report, but I want to be sure, can someone tell me what to do? :)

By regis at Sat, 2005/11/12 - 6:00am