FEB
17
2005

OSNews Reviews KDE 3.4 Beta2

OSNews have written a review of KDE 3.4 Beta2. Highlights picked out include the new application welcome screens, the many improvements in KPDF, the new system ioslave and text to speech support. The conclusion, "it looks like the developers have done a great job with this beta release".

Comments

The fuzzy clock is very practical, fuzzy to the nearest 5 minutes. Don't usually need any more detail than that.
Would be nice to be able to set kicker transparent, but not the clock, though.

Thanks for one great release after another.


By Andy Marchewka at Thu, 2005/02/17 - 6:00am

that is possbile, just set a background color... the problem is more to get it transparant again, after you gave it a color once. I have no idea how to do that...


By superstoned at Thu, 2005/02/17 - 6:00am

set the background color to the window background. this work in 3.4 at least =)


By Aaron J. Seigo at Thu, 2005/02/17 - 6:00am

aaah, thanx... that'll do it!


By superstoned at Thu, 2005/02/17 - 6:00am

for 3.4 i doubt it, due to font consistency issues across OSes.

and yes, styleclock's OpenGL dependency is way over the top. and not just because not everyone has OpenGL libs, but also because not everyone has hardware accel'd OpenGL. and without that OpenGL just sucks (CPU..)

in KDE 4 the current clock applet will be hitting the bitbin, however and wlil be replaced with something better. don't know what exactly yet, but the current clock just doesn't do it for me. it's the slowest of the default applets to load. it's also the biggest of the default applets.


By Aaron J. Seigo at Thu, 2005/02/17 - 6:00am

sounds good :)

hope you can give it some love...


By superstoned at Thu, 2005/02/17 - 6:00am

I use both windows XP and Linux. In windows XP Internet explorer loads in less than a second in KDE it takes around 3 seconds on first attempt after that its identical. The second slowness is when a directory has so many files in it like usr/lib it takes 4 seconds until the folder gets displays. In windows it makes no difference the windows explorer displays the files instantly. The third it is slower to load than windows XP however that is difficult to compare because in Linux there are other factors, for example on my laptop it takes only 30 seconds to load windows and I am off and working and in Linux from turning on the computer to starting work on it takes nearly 2 minutes that is very considerable difference even though I have turned most services off in Linux.

I am using Fedora 3 and I am running KDE 3.4 beta 2. I can say that there is considerable speed improvement and its very noticeable and it looks beautiful like the new icon zooming. I think developers should be congratulated on that. Every Kde version so far has been getting faster than its predecessor and so have the other great programs in Linux that I use constantly (Inkscape, Gimp, Scribus). The only exception is Open Office that is just to slow to start up (nearly a minute that is a joke for what should be a very good programme) and that frustrates me so I don't use it I use instead Kword.

Keep up the excellent work !!!


By Anonymous at Thu, 2005/02/17 - 6:00am

For the 3 seconds inital loadup, try enabling "preload an instance on kde startup" in performance tab under settings". If the time displaying dirs with lots of files in is a problem, turning off previewing may help, however that might not solve it because kde (and anything *nix) has to look at the magic for every file to find out what it is, rather than just looking at the file extension.


By mikeyd at Thu, 2005/02/17 - 6:00am

Wouldn't caching this in file attributes help? Are we ever going to see proper ACL and EA support in KDE?


By Jel at Thu, 2005/02/17 - 6:00am

The thing is, preloaded instance forgot to clear session
information (unless this behavior is intentional)


By CP at Thu, 2005/02/17 - 6:00am

Agreed, comparing preload IE dll's with a not preloaded konqueror is not fair. Compare firefox start-up on both platforms instead.

IIRC the last time I check the filemanager, two years ago or so, all icons were displayed immediately as blanks and then, like an after burner, the right icons were filled in. This is also how it works on windows. No idea why that is changed, might be the KIO generalization here, but I agree it's not comfortable to have to wait for a few seconds before being able to do a file operation.

Anyway, I work at the office mostly on a dual boot 700MHz laptop. Currently I'm working again w/ W2k, and I find it quiet slow compared to debian's kde-3.3.2. Esp. the 'Start' menu is so annoying one has to wait on every menu for a second or so.
Btw, this day I spent all morning to get windowsupdate working. It used to work, but now when it starts downloading/installing the updates, nothing happens (the progress bars on the download dialog stay at 0%). Although I consider myself a power user (at least on linux, where I have strace and friends), at windows I felt really helpless. Probably this installation is doomed in time ..


By koos at Thu, 2005/02/17 - 6:00am

Now that I think about it, the thins that I was reffering to were not so much KDE.

- nasty dragging artifacts taht quickly dissapear
- slow bootup time of OS
- slower Firefox bootup than Windovs

Though in KDE's case, I have also found some programs start up slower than they should. Like Kcalc, for example. But overall, when comparing only KDE programs, the difference in speed is not that great and mostly just at startup.


By Al at Fri, 2005/02/18 - 6:00am

> if you add more things it *never* can get faster

this is actually not true. and easily shown with the following thought experiment: there is a piece of software that takes 10s to complete its task. 5s of this is spent in one particular part of the code, which is sped up by a factor of 10. the software now takes 5.5s to complete its task. however, a new feature was added that takes 1s to complete. the software now takes 6.5s to complete its task. more features. faster than the last release.

or. there is a piece of software that takes 10s to complete its task. a new feature it added that provides another way of accomplishing the same task in certain situations, but is 3x faster. when this new faster method is not applicable, the old method is applied. but when it is applicable, there is a savings of 6 1/3rd seconds. more things added, faster.

and of course there is the issues of perceived speed. there are ways of making a computer _feel_ faster even though it isn't going any faster at all. the perception is all that matters. this can happen by reordering operations so that the software allows the user to interact with the application sooner (progressive rendering in web browsers, for example).

look at khtml as a great example. it has had features added to every release. and yet it continues to get faster. often because one of the above three concepts has come into play.

it is accurate to say that adding new code without thought and not paying any attention to matters of optimization will cause a system to continually slow down. fortunately, this is not how things generally work in the KDE project.

peace 'n luv, aseigo


By Aaron J. Seigo at Thu, 2005/02/17 - 6:00am

What if the things you need to do can't be done?

What if the added features permit you to do the task in less time?

It is good practice to get everything working before optimizing.

Derek


By Derek Kite at Thu, 2005/02/17 - 6:00am

Obviously you are no programmer.

Let's take a very simple application. It holds a list of 1,000,000 names. It tries to find one particular name, so it searches through the list. This is very, very slow.

Now lets add a thing: a hash table. This will take about five times as much code. It also needs more memory. But it sure is a LOT faster. Searches are almost instantanious.

This is a very simple example of how simple, clean software loses from larger, more complex software. This also hold true on a larger scale, the scale of a kernel, of KDE, of X.

It's just about being smart and it is most certainly not about removing code.


By Erik Hensema at Thu, 2005/02/17 - 6:00am

That's just plain silly. Run time isn't a function of "stuff". Many times optimizations require adding more code to a project.


By Scott Wheeler at Thu, 2005/02/17 - 6:00am

"Long live the K Desktop Environment."

Seems like a great release.


By Kde user at Thu, 2005/02/17 - 6:00am

Pages