Testing the KDE 4.2 Release Candidate, On Windows
Verunks writes "Ars takes the KDE 4.2 release candidate out for a test drive on Windows. The popular open source desktop environment has moved beyond Linux and is becoming increasingly robust on other platforms. Even KDE's Plasma desktop shell is now Windows-compatible."
Portability was one of the goals of KDE4, and it is encouraging to see it works.
Now if only the other parts of it would stop sucking...
How about making it stop sucking before making it portable?
If you want an example as to why you should prioritize this way, look at the popularity of NetBSD.
Today's Daily KDE4 WTF: My clock has two lines. The first line is the time, in military time -- 08:31. This works fine. The second line is the date: Tue, 27 Jan. It might be 27 January, but I can't tell, because the T and half the u in Tue, and most of the n in Jan, are cut off.
Then there's the Gnomification / castration of configuration options.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
There shouldn't be bug report for this category of obvious flaws. If you had one look on the desktop you would have seen it.
Fallacy. If we had one look at the OP's desktop then we would have seen it. Unfortunately, the users who test KDE cannot possibly test every permutation of hardware that exists that supports KDE. It's simply impossible. However, I'm willing to bet that the machines they did test on did not exhibit this problem. Hence, they never knew a problem existed.
So... the bug report will be marked "Cannot reproduce". Then a couple other suckers that were so annoyed by it that they took the time to create an account in the bug system will post "Still reproducible on 4.4", but it'll never get fixed. And even if it does get fixed, the bug report will never be changed from "Cannot reproduce" to "Fixed" since it's lost in the morass. The people who filed and posted 'me too' and the people that read the report and didn't register will all be even more pissed off.
Testing and bug tracking does not work well when the underlying code is really buggy. Quality of a program should be judged by its worst part... it's better to have good quality throughout than to have some perfect code mixed in with some really bad code. IOW, there shouldn't be problems with just a couple fields being a couple pixels off like that.