The KDE Project yesterday
announced 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 informative
preview of
the much-improved KDE 3.1 is available on the KDE Promo site.
KDE 3.1 RC1: Ready for a Short Test Drive
Dot Categories:
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.
I disagree. kdelibs should not be bloated with redundancy. That's the whole reason theres a seperate package for the extra icon sets.
If we're worried about redundancy, then why wasn't Crystal put into -artwork instead?
Because we need atleast one icon set in the main kde distribution. You can't have redundancy without something to be redundant about =)
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.
They are not GONE, they are moved to a new package. That makes them an optional part of a KDE installation, but will still be very commonly distributed.
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.
er, and by "local displays" i meant "locolor displays" *sigh*
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.
--
JRT
Title says all. Still, it's a really nice icon set, I've been using it with KDE 3.0.4 for a long time now.
The delivered version is not, but all icon sizes are automatically generated from SVGs.
I'd really like icons that scale with the size of the panel. That and 37 pixel wide desktop icons ;)
There is a SVG variant of Crystal, just don't know if it's already in 3.1.
Hi,
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.
Regards,
Tackat
Wow, cool. I always a associated SVG with a rather cartoonish look, not "shiny" like Crystal is. I didn't know that you could create such icons with SVG.
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.
Check f.e. http://www.svgopen.org/, http://www.kevlindev.com/ and www.carto.net to see some useful applications.
As a conclusion:
SVG for icons is nice - but with SVG you can do much more and it should really have more weight within the KDE project!
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,
Rob.
Hi Rob,
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.
Regards,
antialias
Hi,
>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,
Rob.
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... ?
Missing mStartupFolder declaration? I thought it was a duplicate declaration, patch to fix this:
http://kdewebcvs.pandmservices.com/cgi-bin/cvsweb.cgi/kdenetwork/kmail/k...
Well - I certainly had to add one, since there was none
mStartupFolder is undeclared
After adding it to the list of QStrings in kmmainwin.h it finished up happily.
Yeah, seems like two people added it to fix without coordination after tagging. :-)
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. :)
Thanks for the tip.. I needed that
Well the beta2 is as stable as KDE 3.0.4. Never had any crashes. Again perfect work from the KDE team.
Dim
Check out the feature status page to see what isn't quite finished: http://developer.kde.org/development-versions/kde-3.1-features.h
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
Check out the KDE 3.0 feature page to see what's not yet finished for 3.0. Remember, coders are lazy in updating documentation.
HAHA!!! Good point, but I noticed it was updated about 2 (3?) weeks ago, so it's atleast a starting point =). Plus there's that nice quick link to the critical bugs on top.
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.
Sorry, I think the question might be out of topic...
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
Thanks a lot for the info. Maybe this weekend.... after I do backups ;-)
I experienced exactly the same a while ago
with a KDE version from CVS
(on a PIII desktop machine on a 2.4 Linux kernel).
So maybe the freeze is not related to the kernel
or the laptop.
Some days later the problem was just gone.
I've no idea what the reason has been.
I cannot remember doing anything about it
like deleting my ~/.kde
A patch was committed today to address a critical bug, that I don't think got into RC1 (I'm not 100% positive about that, but I'm pretty sure). I advise you guys to apply it before testing out RC1.
http://bugs.kde.org/show_bug.cgi?id=48923
Or simply keep in mind what http://www.kde.org/info/3.1.html says:
- Deleting an icon on the desktop deletes all the contents behind it Bug #48923 )
yes, but I'm saying it would probably be better to apply the patch rather than remembering not to delete stuff =)
Isn't there a way to improve KDE start speed ?
It's very too slow !
Yes, just update your hardware :-)
That is not an acceptable answer (even though you're joking)
But the original poster may want to check inside his startkde script and delete services he does not need.
Also, if you compile it with a newer version of gcc (or use Intel's), it will run faster.
I do wish the developers would try to make speed more of an important area.
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.
Only libraries that are written in C++. That includes the obvious Qt, and FAM, if you have it ( a lot of people miss that one ). There may be others, but I don't know of any.
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.
Rich.
Runtime and startup time are very different things.
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.
"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."
It may make relocation time negligible, but startup time is not solely caused by relocation.
of course it isn't, but it is a large chunk of the problem. KDE can always use more optimizations and continues to get them. there are limits, however.
of course, having seen how fast the latest SuSe was even on ancient hardware, i'm quite impressed at how fast it can be when properly built and integrated.
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
How hard is it? Can I do './configure --prefix=/ && make install' and expect it to work? Will I break existing apps? Do I have to recompile everything?
I don't know what your problem is: Update binutils, glibc, gcc, your hardware, XFree, KDE & Qt, delete fonts, compile from source, change compilation settings, ...
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.
--
Evan