The KDE team has released KDE 4.3. This release comes packed with improvements and bug fixes - in fact, over the last six months, 10000 bugs were squashed, 2000 feature requests handled, and 63000 changes were checked in by 700 people. We've already talked about this new release in quite some detail last week, but let's take a look at the most important new features anyway.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-07-24
Some of the responses you are receiving are indeed bizarre.
Operator: 911. May I help you?
Caller: My table saw just went haywire and cut off my arm!!! I'm losing blood fast!!! Help!!!
Operator: Have you gotten an anatomy book and studied it carefully to see exactly what the problem might be, and why owners of other table saws might not have had their arms cut off?
Edited 2009-08-05 14:49 UTC
Member since:2005-09-10
But at least you need to listen to people explaining what the problem is instead of dismissing them offhand, and blaming the toolkit. Like it is known that kwin exposes more features of the graphic card than other compositing window managers. This is how bugs are found in the drivers, and actually NVidia acknowledged that the problem is on their side some time ago and they issued a fix - but don't let that bother you. Just keep harping on how KDE sucks for YOU ignoring other's comments or requests for more information. You're at 10% now (of the total number of comments) basically repeating yourself over and over again. Keep up the good work, and you may reach 20%, maybe then you'll accept that we HEARD YOU THE FIRST TIME, and you can stop wailing...
Member since:2005-11-21
It should not take noticeable amounts of time to redraw a section of a double-buffered window during an exposure event. I don't need to look at code to know that that is bad behavior on the part of the toolkit.
everything thing but Qt4 is fast on my system.
Member since:2005-07-06
You can try another variable - the drivers and the graphics chipset - as has been explained quite a few times in this thread and as I'd explained in another post. If it's KDE 4's fault then if you vary the graphics driver and the chipset then the issues should remain. They don't. ATI's Linux drivers are junk right now if you expect everything to work well.
Either you can't face up to the fact that ATI's Linux driver support is pretty useless or you're labouring on this for reasons that are best known to you.
Member since:2006-01-02
You still can't explain to me why performance of every other toolkit and DE is great, only KDE 4 has problems. From my point of view, the variable is the desktop environment, and changing that variable from KDE 3.5 to KDE 4 using the same drivers, same X server on the same hardware results in drastically different performance. I vary the variable again by using GNOME, or XFCE, or Fluxbox or whatever, different compositing managers (besides KWin 4) and performance is still fine. What else am I supposed to believe, other than that KDE 4 does not make efficient use of what is otherwise decent and performant hardware?
Member since:
2006-01-02
I don't need to look into the code and do a thorough reductionist analysis when the behavior is crystal clear: everything but Qt4 is slow on my system. If *everything* was slow, sure, blame the drivers. However, I find it very hard to believe it is just the drivers' fault if only one toolkit ever seems to have a problem. And if it is the drivers' fault, it's because the toolkit is making use of edge cases which the other toolkits can clearly get by without using and Qt4 should do the same. Again, don't need to look at code to know the correct answer here.
It should not take noticeable amounts of time to redraw a section of a double-buffered window during an exposure event. I don't need to look at code to know that that is bad behavior on the part of the toolkit.