The KDE Project yesterdayannounced the release
of KDE 3.1 RC 1. This release, while important, will have but a short lifespan (RC 2 is scheduled for next Monday), and so binary packages are not planned.
A couple of points to consider: First,
if you are wed to the hicolor icons, please note that they have been moved
to the kdeartwork package; the other packages ship only with the new modern
and attractive Crystal-SVG icon theme.
Second, Klipper users who experience slowness or possible crashes in Konsole
or KMail with this release should try disabling the Klipper syncing options,
and then check
the KDE 3.1 Info Page
about reporting results. Please give this release a thorough testing
so KDE 3.1 will be good and ready on schedule! A short but informativepreview of
the much-improved KDE 3.1 is available on the KDE Promo site.

Comments

"if you are wed to the hicolor icons, please note that they have been moved to the kdeartwork package"

Aargh! These are wonderful icons. They have a classic and simple look without being ugly. Eye candy is good, but candy is desert. Sometimes a sensible main course is what is desired. At least keep hicolor in the kdelibs package.

Agreed. All the new "eye candy" to me is just clutter. I don't like keramik and I don't like the crystal icons. Last I checked the hicolor default style was still part of KDE, so that's good, but it's unfortunate that the hicolor icons are now gone. You can bet I'll be picking them up to use as my main set.

i think it is important to remember that while there are those who will still install and use the HiColor theme and icons, there are many who will now go with the KDE default look. many already use a different style than the default (e.g. litev3 is very popular, which btw is now the default style for local displays)

so while it means some will not use the default anymore, many others now will. judging by overall response, probably many more others.

I'm not really "wed" to the "HiColor" icons, what I AM wed to is my icons!

There is more than one issue here:

I don't like the 3D folders and so I use the old 2D folder icons. I now have quite a few folder icons for various purposes many of which consist of the 22 pixel icon combined with the 32 pixel folder icon for 32 pixels and a half size 22 pixel icon combined with a plain color background the same color as the folder (I use FFDCA8 for all folders, but have nothing against using different colors) for the 16 pixel icons. Note that it occured to me that this could be done automatically. That is, for example, there is a directory: "~./kpackage" so it could automatically have an icon as I have made for it.

Many (non-kde) programs come with an icon or I have 'borrowed' one. These look best with the HiColor icons. They look very much out of place with the Crystal Icons.

What happened to usability. Everaldo's icons may be great art, but at 32 pixels they are not very usable. They look fuzzy and lack contrast. They simply not easy to distinguish from similar ones.

Yeah, at the current point of time the name of the theme is a bit misleading. Actually we _do_ have vector data for most (about 70-90%) of the crystal-icons. And technically it _would_ be possible to use them on the fly as well as pregenerated. It's just that ksvg2png while giving excellent results for 98% of all icons needs more testing and that we still have some icons left for which SVG-data doesn't exist yet.

So instead of releasing something that hasn't been properly tested we decided to use Pixmaps (which have been partially autogenerated from the SVGs) instead of using the "real" data.

To make the transistion easier we decided to name the theme already "Crystal SVG" to make the transition easier. Wait for some news concerning this topic which will be released soon.

To my opinion SVG is one of the best web-technologies to watch, as a graphics-exchange format, as a graphics format for mobile devices, as a printer description language (combined with other XML-technology, such as XSL-FO), etc. ...

I therefore think that the KDE team should give SVG top priority as a base-technology for the KDE-desktop (SVG enable all KDE-applications) and as an integral part of the Konqueror browser. Combined with other XML technology and scripting, SVG allows very useful applications and is for the first-time a fully documented vendor-neutral graphics format as an exchange format between different applications and platforms. I am very happy that ksvg (svg.kde.org) already exists - but I think that it should have more support and priority within the KDE team than it has now.

As a ksvg developer, I am very happy with these comments :) As a
matter of fact, I'll forward them :)
I looked at carto.net and it looked very nice, but I havent really found
the time to study it.
Cheers,

can you recommend some svg graphic tools for creating svg icons? Tackat & everaldo use Adobe Illustrator, but I don't want to use proprietary tools, especially not Adobe products (you know the story when Adobe lawyers threatened KDE with lowsuit for using name KIllustrator). So, can you recommend an open source graphic editor which can export svg fromats that can be read by ksvg?
I tried Sodipodi, Karbon etc, but the results were poor. Either their exported svg files can't be read by each other or can't be read by ksvg properly.
Now we have a situation that the next default icon theme for KDE 3.1 is being created by artists who are running windows or Mac platform with a graphic tool from a company known for threatening KDE and other open source projects.

>I tried Sodipodi, Karbon etc, but the results were poor. Either their exported >svg files can't be read by each other or can't be read by ksvg properly.
>Now we have a situation that the next default icon theme for KDE 3.1 is being >created by artists who are running windows or Mac platform with a graphic tool >from a company known for threatening KDE and other open source projects.

I agree, it is not ideal.
Best thing to do IMHO is to support the oss alternative, karbon14, by
sending in bug reports and wrongly exported svg files, then we can fix them. Believe me, we are really aiming to help the artists on a nice vector drawing app, that is our first major goal, just tell us where we fall short currently :)
Cheers,

I'm compiling RC1 on my home system from work as we speak. Can't wait to get home and try it. Ran into a few compile snags - one with kfontinst and the locations of freetype, one with kmail and a missing mStartupFolder declaration, and one large mess in kmidi. I fixed the first two - I just bypassed compiling kmidi since I don't use it.

I suspect the first and last are more related to problems with my setup than with KDE itself. But as for the kmail error... I can't see that working without help on other systems... ?

It seems natural to me that the tarballs should be compiled cleanly before being released, to catch these things :) It may only be an RC, but we still want as many people as possible testing it, I presume. It was a simple fix, but other people may not think so. :)

And there are still minor bugs to take down (encapsulated messages in kmail, replys to html messages n kmail... get on the reporting, and some font problems to name some I've seen), so start reporting them so KDE 3.1 is as bug free as possible

I have some issues with Konqueror file manager mode with linux 2.5 series
kernels, I use 2.5.44 currently and when i start konqueror it just hangs, the web browser mode works perfectly though
I use offical debian packages for beta2 from kde.org
ANybody experienced this issues?

mmmmm.... I'd like to give it a try, but 2.5.x series of the kernel really frighten me... aren't there any chances of destroying the filesystem or similar? My laptop uses only acpi, and I really need some upgrade, I hope they have done it right for 2.6.

Well
I use 2.5.44 on the laptop myself
I have got everything to work including ACPI
support, I haven't had any issues so far
except the konqueror hang
which is kinda strange given it only hangs
in file manager mode

I'm a little confused about compiling KDE with a compiler that's different from the system's default compiler. gcc 2.9x and gcc 3.x are binary incompatible. Does that mean I have to recompile all libraries that KDE depends on with the new compiler? What about system libraries such as glibc?

It would be nice if some expert can write a two-paragraph "HOWTO" for ignorant folks like myself.

This is not something that should be attempted if you don't know what you're doing. If you want to use the new compiler I strongly suggest you upgrade to one of the newer releases of your distribution rather than trying to do it yourself. To gain the benefits you're looking for you need to upgrade glibc, gcc, binutils etc. and all C++ libraries.

Upgrade to glibc 2.3 to improve startup time (with Prelink). The startup time problems you see in KDE are the results of problems in ELF and gcc. glibc 2.2.5 featured comb-relocs which speeds it up 30%-50%. prelinking should make relocation time negligible. Also something that kdeinit does.

Intel's compiler won't make KDE run or start faster, it doesn't excel at code like KDE's (it prefers math-intensive stuff).

gcc 3.2 is about 15% faster for run-time. Yes, you need to recompile all your libs for it.

Well, kdeinit doesn't help you much with dlopen'ing libs, though, so linking time is still major -- on my box w/ combreloc loading KHTMLPart, kjs_ecma, etc., takes a noticeable amount of time. Ditto for libkonq_sound - dlopening it seems to cause a 1/3 second lag, although I do not recall whether my profile-point would have caught it initialization (i.e. presumably connecting to aRtsd), so some of it may not be dlopen itself in this particular case

Try poking around the startkde script and remove the bit that scans for plugins. I've told people to do this and be delighted - cutting the startup time to 50% or even 33% of what it was. I'm still of the opinion that it should be forked off in the startup, and executed after 60 seconds.