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 download.kde.org. 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.
Dot Categories:
Comments
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?
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
There are two ways to be safe:
1) Backup your important data;
2) Stick to official Kubuntu packages.
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:
http://liquidat.blogspot.com/2005/08/kde-35-alpha-1.html
But after that I tried kdesvn-build, and that was even better:
http://liquidat.blogspot.com/2005/08/another-kde-building-tool.html
Regards,
liquidat
With kubuntu you can use the package debootstrap to install KDE3.5 and keeping KDE3.4.3
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.).
Alfred
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?
Thanks!
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.
_c.
The trouble is that my notebook can only read CD/DVDs, but not write them :-(
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)
Thanks, but I need a copy of vmware to create the vm to launch with vmplayer, is it right?
Check out QEMU. Homepage: http://fabrice.bellard.free.fr/qemu/
Your distro probably packages it. Start the cdrom with:
qemu -cdrom cd_image_file.iso -boot d
man qemu for more information :)
Thanks, I'll try this!
It seems promising...
It seems the Live CD is now available.
Yes, you are right.
Thanks!
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.
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?
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.
this still doesn't work? i thought it got fixed... at least you can now burn cd's from media:/ directly with k3b...
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.
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 KDE4...it'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.
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.
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.
Leo:
"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."
LB:
"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.
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.
Is there already a bug report for this? If yes, can you give the number. (Thank you!)
Have a nice day!
http://bugs.kde.org/show_bug.cgi?id=73821
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!
I reported it in august:
http://bugs.kde.org/show_bug.cgi?id=110951
(or bug:110951 for the ALT+F2 lovers out there).
And its not even confirmed yet.
Was I too vague in the bug description?
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?
Maybe you should try using the release that is supposed to be broken, ie KDE 3.5, instead of a completely different version?
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?
You can ignore this wrong dependency (--nodeps).
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.
KDE 3.5 went into feature-freeze before Beta 2 so RC 1 will hardly have new niceties.
but it's sill possible. The new style for Kopete was commited because it is like data file, not a new feature in c++.
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.
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.
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.
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"
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.
> Is there a standard way to install kde 3.5 RC1 on Suse ?
Try adding their KDE yast-sources from the supplementary folder.
http://ftp.tu-chemnitz.de/pub/linux/suse/ftp.suse.com/suse/i386/suppleme...
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
Hi,
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) ?
Thanks!
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...
I second that...
I third that... :)
as do i !! especially since debian and kde are supposed to have such a big cooperation agreement...
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
cool... great...
i'm looking forward to really seeing KDE 3.5!
Hello,
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*,
int)'
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
regis@REGIS:/multimedia2/src/kdeutils-3.5.0$
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? :)