Linked by Thom Holwerda on Thu 27th Nov 2008 21:45 UTC, submitted by lemur2
KDE The KDE team has released the first beta of KDE 4.2, slated for release coming January. Quite a lot of new features have been added, as well as lots of bug fixes and performance improvements. This release also makes a lot of strides to feature parity with KDE 3.x, by adding those small little features that KDE 3.x users are barely aware of, but which were missed in KDE 4.0/4.1, such as taskbar grouping, multiple rows in the taskbar, panel auto-hiding, a traditional icon desktop through 'full-screen' foderview, and so on.
Thread beginning with comment 338560
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: speak for yourself
by werpu on Fri 28th Nov 2008 10:15 UTC in reply to "RE[3]: speak for yourself"
werpu
Member since:
2006-01-18

"And it's been a year of embarrassment and back-pedaling for KDE4 fans whether they admit it or not.

"Everything is relative..."

Thanks for helping make my point. ;-)

KDE4 is far more of a re-write than people realise.

Apparently that's only true when it is convenient from a PR perspective. Because 10 months ago in this very forum, when I referred Aaron Siego to this:

http://tinyurl.com/4gus

he said:

"...except that the article doesn't particularly apply to what we did. the vast majority of the code base did not see a rewrite (don't like new names like 'okular' fool you, for instance), most of the new code was filling in gaps that were never filled in the first place..."

So yeah. I guess when it comes to KDE4 PR everything *is* relative, in a way. Spin aside, yes, KDE4 really was a rewrite. And Joel's advice has proven to be right, again.
"


Well it depends on what you see as major rewrite. Thing is if you look into the core codebase of KDE, that it is one of the best and cleanest codebases I have ever seen in my life. And that says a lot for a C++ based system which are inherently awful.
The core mechanisms were excellent from the beginning. One of the reasons why kde is so much faster targetting new grounds than Gnome, they got it right from the beginning. Gnome still suffers from the fact that they are in C instead of an OO language and they try to make everything different than KDE and then come up with a similar solution.

So the major issues in KDE4 are probably some cleanups in the frameworks which were overdue, the sound system for instance, and the complete change of the desktop metaphor. Why should they change things like the component model etc... when they are perfectly viable and flexible!

KDE probably currently still is the best desktop environment from a software engineering perspective with NextStep/OSX being second!

Reply Parent Score: 4

RE[5]: speak for yourself
by sbergman27 on Fri 28th Nov 2008 10:29 in reply to "RE[4]: speak for yourself"
sbergman27 Member since:
2005-07-24

One of the reasons why kde is so much faster targetting new grounds than Gnome, they got it right from the beginning.

Whoa, there! Aren't you overlooking the topic at hand? Namely that KDE4 is taking so freaking long to become usable? What is it? Three years? One year after its highly premature 4.0 release? It may *target* new grounds quickly. But it certainly has not *reached* those grounds at all quickly. And that is a verifiable, empirical fact.

Edited 2008-11-28 10:32 UTC

Reply Parent Score: 4

RE[6]: speak for yourself
by lemur2 on Fri 28th Nov 2008 10:50 in reply to "RE[5]: speak for yourself"
lemur2 Member since:
2007-02-17

"One of the reasons why kde is so much faster targetting new grounds than Gnome, they got it right from the beginning.

Whoa, there! Aren't you overlooking the topic at hand? Namely that KDE4 is taking so freaking long to become usable? What is it? Three years? One year after its highly premature 4.0 release? It may *target* new grounds quickly. But it certainly has not *reached* those grounds at all quickly. And that is a verifiable, empirical fact.
"

That seems to be grossly unfair.

KDE4 will have three standard releases before its first year is up, which is way faster than at any time before.

http://en.wikipedia.org/wiki/Kde#Release_cycle

KDE 4.0 was "usable". It was a desktop, with menus, a taskbar etc, etc ... it wasn't feature complete but this is the way that open source is developed.

You don't release open source only after its all finished ... instead, with an open source project, you "release early, release often".

http://radio.weblogs.com/0103807/stories/2002/12/01/understandingTh...

"This is a pretty common tenet in the Open Source world and where commercial developers often go wrong. If you are an ex-commercial developer then you want desperately to reach a "1.0" stage or a "near functional", "mostly baked" stage before going live. You wouldn't want to release something piece meal, would you? After all -- that's the way it's done.

Actually no. In the Open Source world, that's not how it's done. The best Open Source projects tend to start small, release early, release often (RERO) -- even if it's only a little bit of functional (but useful) code. "


http://osdc2005.cgpublisher.com/proposals/18

http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar...

Release Early, Release Often

Early and frequent releases are a critical part of the Linux development model. Most developers (including me) used to believe this was bad policy for larger than trivial projects, because early versions are almost by definition buggy versions and you don't want to wear out the patience of your users.

This belief reinforced the general commitment to a cathedral-building style of development. If the overriding objective was for users to see as few bugs as possible, why then you'd only release a version every six months (or less often), and work like a dog on debugging between releases. The Emacs C core was developed this way. The Lisp library, in effect, was not - because there were active Lisp archives outside the FSF's control, where you could go to find new and development code versions independently of Emacs's release cycle.

...

But by a year later, as Linux became widely visible, it was clear that something different and much healthier was going on there. Linus's open development policy was the very opposite of cathedral-building. Linux's Internet archives were burgeoning, multiple distributions were being floated. And all of this was driven by an unheard-of frequency of core system releases.

Linus was treating his users as co-developers in the most effective possible way:

7. Release early. Release often. And listen to your customers.


If you are going to write opinion about open source projects, it perhaps wouldn't hurt you to read "The Cathedral and the Bazaar" and perhaps find out something about open source development practices.

http://www.catb.org/~esr/writings/cathedral-bazaar/

http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

Edited 2008-11-28 10:58 UTC

Reply Parent Score: 3

RE[6]: speak for yourself
by aseigo on Sat 29th Nov 2008 00:47 in reply to "RE[5]: speak for yourself"
aseigo Member since:
2005-07-06

"Namely that KDE4 is taking so freaking long to become usable? What is it? Three years?"

It's been less than a year since the first release, Plasma itself started taking real shape maybe 6 months before that, with the time leading up to that being spent working on the Qt4 porting, kdelibs organization and merging things like Solid and Phonon.

your negativity and purposeful positioning of things in the oddest ways just to be harsh is really disturbing.

you were a huge critic, i know, and maybe it's a little galling to watch things actually come together. i mean, now you're bitching about how long it's taking? yeesh.

and yeah, go look the Plasma changelog for the last four months and then maybe consider backing off from the chest pounding just a little bit.

Reply Parent Score: 2

RE[5]: speak for yourself
by gustl on Fri 28th Nov 2008 11:44 in reply to "RE[4]: speak for yourself"
gustl Member since:
2006-01-19

As a long-time KDE3 user and a now short-time KDE4.1.x user I want to share my experience with KDE4 here:

I use Fedora 9.

Installation was quite OK, no big issues there.

I wanted to configure KDE to my likings, and knew it would be DIFFERENT to KDE3. I have no problem with that.

So off to the kicker setup: I found the configuration panel, but no color there. I go to the KDE main configuration utility, change some colors there, but nothing I did changed the kicker color.

I complained about this in a forum, and I even got an answer from Aaron Seigo (thanks, Aaron, good work!).

Now for all who want to know how to change the KDE4 kicker background color:

You need to install (!) a theme (!) which actually respects the KDE4 global window background color settings (!!!).

You know, I hunted this thing down for more than a week. And I really felt pissed off. Because that is exactly the reason I don't like Gnome. The standard settings are not to my liking, and to change them you have to hunt down how to change them for a week. If the Gnome standard settings are to your liking, you will be fine with Gnome, it is a good desktop after all, but if not, you are in a hard place.

This experience made KDE4.1.x feel like an early beta. If they had either provided a separate color and transparency variable in the kicker configuration dialog, or had made the standard theme use the global color settings, this would have been a non-issue. This still leaves the road open to other themes which ignore the global color settings, but it avoids confusing users.

For configuration of something there are some human interface principles which explicitly are NOT transferable when it comes to application design:
1) You have to be able to learn it fast, at best it is self-explanatory. GUIs are faster learnable than a config file.
2) Something which is in principle configurable needs a possibility to be changed from the GUI config utility. It is faster to search through GUIs than to search through config files. Effects of changes can be visualized immediately in a GUI.
3) Something which is in principal configurable, and has a config item in the config GUI, has to react to this setting, under any and all circumstances. Otherwise it will be experienced as a BUG, be it one or not in reality. Best example of this NOT being respected are the various login themes of the various distros. They all override the settings which are given in the KDM settings dialog. Horrible. Hunting down where to switch off the theme takes a week for Debian 4.x.
For Fedora 9 I have still not found out where it is. This is also one of the reasons why "Linux" is "difficult" for windowsers. I do not know a single desktop item in Windows which does not react to the corresponding settings dialog. In Linux, there are several such instances, all of them having a good reason why they don't react, but this still does not help the user who knows nothing of the internals.

Reply Parent Score: 2

RE[6]: speak for yourself
by leos on Fri 28th Nov 2008 16:21 in reply to "RE[5]: speak for yourself"
leos Member since:
2005-09-21


You need to install (!) a theme (!) which actually respects the KDE4 global window background color settings (!!!).


Wow, sure is funny what sets people off. I can't imagine what kind of early beta you think Windows is, since you can't change the taskbar color at all! Rather than going into desktop settings and changing the theme, a process which hardly requires 5 exclamation marks.

1) You have to be able to learn it fast, at best it is self-explanatory. GUIs are faster learnable than a config file.
2) Something which is in principle configurable needs a possibility to be changed from the GUI config utility. It is faster to search through GUIs than to search through config files. Effects of changes can be visualized immediately in a GUI.


What are you talking about now? Given that the desktop theme can be set in the GUI, this has no relevance to your previous complaint.

3) Something which is in principal configurable, and has a config item in the config GUI, has to react to this setting, under any and all circumstances. Otherwise it will be experienced as a BUG, be it one or not in reality. Best example of this NOT being respected are the various login themes of the various distros. They all override the settings which are given in the KDM settings dialog. Horrible. Hunting down where to switch off the theme takes a week for Debian 4.x.
For Fedora 9 I have still not found out where it is. This is also one of the reasons why "Linux" is "difficult" for windowsers. I do not know a single desktop item in Windows which does not react to the corresponding settings dialog. In Linux, there are several such instances, all of them having a good reason why they don't react, but this still does not help the user who knows nothing of the internals.


I agree the distro customization which breaks this stuff has to get fixed, but lets not forget that in windows it isn't possible to change the theme of the login screen at all, so there is no direct comparison.

Reply Parent Score: 3

RE[6]: speak for yourself
by Soulbender on Fri 28th Nov 2008 16:39 in reply to "RE[5]: speak for yourself"
Soulbender Member since:
2005-08-18

This experience made KDE4.1.x feel like an early beta


My guess would be...because it is effectively a beta.

For configuration of something there are some human interface principles which explicitly are NOT transferable when it comes to application design:
1) You have to be able to learn it fast, at best it is self-explanatory. GUIs are faster learnable than a config file.
2) Something which is in principle configurable needs a possibility to be changed from the GUI config utility. It is faster to search through GUIs than to search through config files. Effects of changes can be visualized immediately in a GUI.
3) Something which is in principal configurable, and has a config item in the config GUI, has to react to this setting, under any and all circumstances


Uh...yes? That's what you use the settings ui for.
The words, they are in English but they make no sense.

Hunting down where to switch off the theme takes a week for Debian 4.x.


If it takes you a week to figure that out I'm afraid the problem is not with KDE.

Reply Parent Score: 3