I'd say if it takes you two stable releases to implement very basic functionality like working keyboard shortcuts, then you suffer from a lack of manpower.
Don't get me wrong -- "We're always hiring.":)
Keyboard shortcuts have worked the whole time (at least for me). Working global keyboard shortcuts, not so much (at least if we're talking about multimedia keys in my case). Somehow KWin's global shortcuts work so in the end I don't notice but Alt-F2 has worked since KDE 4.0 so maybe I'm just not experiencing some long standing bug which you're hitting.:(
It's also hard to believe you can look at the kde4 release announcement http://www.kde.org/announcements/4.0/ and not see the problem. What needed to be explained on that page was that KDE4.0 was not ready for everyday use.
"KDE 4.0 is the innovative Free Software desktop containing lots of applications for every day use as well as for specific purposes. Plasma is a new desktop shell developed for KDE 4, providing an intuitive interface to interact with the desktop and applications..."
...doesn't cut it. It was in an alpha stage, yet the release announcement read like it was a final stable release.
Fair enough (although I'd claim beta quality as opposed to alpha -- based on using the desktop the week leading up to tagging).
What bothers me though the numbering system. KDE 4.0 is a major update. 4.1 is a semi-fix update and etc.
Can't they just go to 4.1.1+ until they fixed the underlining issues with 4.0 before they can declare 4.2 is ready?
The 4.x.y is numbered like this:
Any time features are added or new APIs become available for libraries the "x" goes up. This is why 4.1 was 4.1 and not 4.0.5.
Any release that is a bugfix release only has "y" go up. API could be added in theory if it was essential toward fixing a bug but that would be reflected in the API documentation.
So the 4.2 release will obviously include bugfixes, but it will also be the first release with new features since 4.1.
... but with enough resources, I think you could have reasonably expected to conduct use-case oriented productivity test and a feature count on KDE 3.5 vs. GNOME, and be reasonably confident of KDE coming out on top back then.
Well if anything we would have compared KDE 3.5 vs. 4.0. I know that our respective user bases are quite enamored of their particular desktop but we really don't lose sleep at night just because someone uses GNOME. We're not trying to poach users from a different DE, we're trying to make the best desktop environment. As I already mentioned everyone has their own "best". We hope lots of people will enjoy KDE 4 as it evolves but we neither expect nor demand that everyone likes it better than GNOME/XFCE/Mac/Windows/etc.
And to more directly answer your point: bwahahaha, no, we don't really have tons of resources to do "feature counts" and use-case productivity tests.
Usability analysts like Celeste Lyn Paul do a good job of usability testing and we can definitely use more of the same, but we don't exactly have a huge budget either so for now we rely on volunteer effort.
I'll be surprised if that's the case by the time 4.5 gets here.
Please elaborate, without using mailing list threads where these core developers get flamed endlessly because people don't like something in KDE 4.
I can't (be bothered) because what you see as devs being flamed is what I see as concerned users/developers voices being rejected on the basis that they're flaming.
Well being flamed is being flamed. I've certainly seen people bring up points or features that they think are important without flaming. Typically they get asked to file it in bugs.kde.org, or a developer explains why they think it is a bad idea.
Sometimes it happens that a user will come along and be the tenth person to ask for something that has already been discussed to death on the mailing list. I understand that most people don't have the time to do the kind of searching of mailing list archives required to see if the topic has already been mentioned or not. But it is human nature that people get testy when they hear the same answered point time and time again. Plain obstinacy? Perhaps. But typically unimplemented features that are not rejected on their face but simply due to developer interest or time can be implemented if someone is interested enough to provide a patch.
This is no different from any open source project. A developer has a priority queue of X things to do and unless your proposal is important enough to bump something else off it's not going to get worked on.
Some proposals will never make it in because the developer does not want the program to work that way. Especially changes that make the program less usable by default (i.e. please remove this only visible part of Foo's user interface -- although doing so would make it near impossible to configure for all but power-users). Unfortunate, yes but also how pretty much any open source project works.
I'm not claiming 100% niceness by developers but without something to look at I'm not exactly sure what to tell you.:-/
Horrible?... How so? I ask because the release process is mostly unchanged since KDE 3.5, where apparently it worked well. What do you think has regressed since then?
I wasn't comparing to 3.5 here. I was comparing to the de facto standard for FOSS releases, which is to make something reasonably stable and feature complete, and certainly ready for reasonable third-party development and deployment testing, before you tag it as a beta, never mind a.0 release. Yes, KDE PR tried to do damage control when users expected more from 4.0, but it was hardly enough to counteract such a huge step away from the usual release methodologies.
Well this has been discussed to death a million times over as well
This is just pure insanity. I'm a Linux user and I have no qualms about saying so. You are saying, "Well, it's just the initial release. I'm sure it will get better in like *5* more releases". How can you possibly justify that when the vast majority of the people here that say, "Well, Vista will be better with SP1" get flamed.
Well, how much did you pay for KDE 4.0? How much did you pay for Vista? Did KDE take all copies of 3.5.10 off the shelf when 4.0 was released? (Hint: No.)
KDE4 is literally the linux equivalent of Vista. After 5 service packs (and possibly renaming it KDE 5), it might be usable.
No, it's usable now. I'm sorry if it's not usable for the exact same sequence of tasks that 3.5.10 was but then we're not trying to make 3.5.10, we're trying to make something better.
It's a disaster and a lesson to those that would try to re-write good things because, "We know better".
LOL! Do you know how much source code is in KDE 3.5? There's no way we "rewrote" that all.
However, it does provide an interesting principle about how much change you can put into a project. This is actually the second time KDE has dealt with such a large transition (the first being KDE 1 -> 2).
Now with KDE 3.5 -> 4 our developers were able to produce quite a few positive changes to modernize KDE and take the steps necessary to keep it relevant. Yes, there were features that were dropped that still need to be added again, and some things don't work as well as they used to in KDE 3.5.
What were the alternatives? A straight port of 3.5 to Qt 4? If you seriously believe that, where do you think we started from?...
It took a lot of effort to get the 3.5 codebase onto Qt 4. Believe me, I was there. It took ages to get kdesktop to be able to display its background again, and that was hardly the largest of the broken features. And that was just from the porting process!
Any major changes we wanted to be in KDE 4 had to be there (at least architecturally) before KDE 4.0 due to source and binary compatibility concerns.
So what do you do, take a year or two to re-architect, and another year of bugfixing before you release (and meanwhile become completely irrelevant in the Internet age)?
Or do you take a year or two to re-architect, while application developers port what they can in the meantime and then try and quickly start releasing again? You'll (hopefully) stay relevant but the desktop won't be as shiny.
By releasing early we were able to get immediate user feedback. What if three years down the road we released a polished release that no user wanted to use? At least now we know that desktop icons is a REALLY BIG DEAL for lots of people.;)
By releasing early we were able to keep developers interested. What do you want to do? Create the next generation of KDE, or do maintainence bugfixes on 3.5? You can attract some developers on the basis of Subversion code alone but at the end of the day you need to make releases, especially for application developers.
By releasing early we were also able to maintain relevance. Who on Slashdot hasn't heard of KDE 4 now, one way or the other? =D Although obviously you never want to shortchange your good name, my experience has been that the harshest comments have come from the most uninformed.
I've seen valid complaints about a feature that is missing or doesn't work as well, or how they don't like the way the desktop is handled now, etc. That's all fair enough. But there are also people who complain about KDE 4.0 being tremendously overhyped, that we said it was going to provide world peace, etc. etc. And I don't see why.
I develop for KDE and let me assure you, the 4.0 release was controversial internal to the project as well. We weren't a bunch of developers telling you that we had the best flavored Kool Aid ever, why don't you have a drink? We certainly had developers
Linus is promoting the best option available at the time, without bias. Which is perfectly sane, and valid.
In all fairness, "best" is one of those things that is in the eye of the beholder. When KDE 3.5 was the latest, GNOME was still "the best" for many people.
Basically, KDE has great tech. BUT core developers seem to have some sort of arrogance about listening to the community
Please elaborate, without using mailing list threads where these core developers get flamed endlessly because people don't like something in KDE 4. On the other hand we are always interested in receiving reports of what we could do better (although reasons of "KDE 3.5 did it this way" does not exactly prove the point...)
and some sort of project-deathwish which manifests in a horrible release process,
Horrible?... How so? I ask because the release process is mostly unchanged since KDE 3.5, where apparently it worked well. What do you think has regressed since then?
minor versions that don't work until x.4 or so,
So you're saying that you've had issues for both 4.0 and 4.1 not working until 4.x.4? 4.1 would have been much the same as 4.0.4, with the exception of extra features. I personally did not notice tons of trouble from 4.1 on (although obviously I'm biased;)
and poor support for non-core developers.
No offense but this is a troll unless you have something in particular that you're talking about. The same mailing lists, API documentation, and support tools are available now as were available for KDE 3.5. In addition we now have a Wiki available instead of the crusty old KDE 2.x material, KDE TechBase, and the number of developers has only been increasing.
For instance, the latest KDE Commit Digest shows commits by 249 developers, up from 231 a year before. If we go back to the last Commit Digest from Derek Kite in October 2005 there were 195 developers. Argue about seasonal effects or whatever all you want but the data doesn't support your argument.
Moreover they've alienated some of the very groups they tried to encourage early in the KDE 4 brainstorming process.
Well there are definitely "alienated groups" but who are you talking about specifically?
Finally, they generally seem to suffer from lack of manpower, which they have never really tried to solve.
Well not only is that not true as I already mentioned, but your latter point is also not true. I know it's easy to blame the shift of focus that we employed in KDE 4 on everything, but the fact of the matter is that it actually brought in quite a few developers as well... We have people working on the art, basic desktop and games, areas which were mostly unmaintained in KDE 3. Things like the KDE TechBase I already mentioned were created as part of making it easy to develop for KDE. Again though, if you have something specifically that you have in mind then say so as developer support is a very high priority for KDE.
If you believed the hype the core devs were spouting, KDE 4 was going well, and no help was needed, until the product actually appeared as a release and everyone saw the real situation.
Here's the announcement about the Development platform release where the library API was declared stable. "With a lot of issues facing KDE hackers before 4.0 is a usable desktop, all work on new features and UI is stopped, and efforts focus on fixing the inevitable, long list of bugs." Where's the hype?
The odd thing is that this 13-year-old article recaps research (refereed and published in a respected economics journal) 19 years ago.
Does that make sense to someone?
Well the article basically goes over arguments against the test methods used by Dvorak and points out some contrary studies. Then the article author complains that he had already covered said topic 6 years earlier and the myth persisted. That's what the summary is referring to.
I know that the Slashdot editing has a very low reputation around here but I was pretty interested to see how much work was done on this article writeup. You can see mine at the Firehose entry. The Slashdot editor even went to the trouble of looking up prior Dvorak-related articles (and taking the trouble to notice the article I submitted was 13 years old -- whoops)
Months or years after TMI, the goverment NRC hacks admitted to a gross error. They estimated the rate of hydrogen production based on atmospheric pressure, whereas the pressure in the containment was significantly higher.
Well I'd have to look at the timeline again but the proximate cause was a stuck open primary relief valve attached to the pressurizer steam space which would certainly have dropped pressure far below nominal (although still above atmospheric). I know that eventually the relief valve was blocked but I'm not sure if that happened before or after meltdown commenced.
Either way though you are correct in pointing out that there was essentially no threat to the public which makes the ordered evacuation unnecessary. (Even if you assume a hydrogen bubble it's not like the containment was going anywhere...)
And if you control the temperature in a downward direction, that would be called "cooling".
You can try and regulate temperature back down but you must have a heat sink, otherwise no cooling occurs. For instance for a standard pressurized water reactor which is cooled by creating steam, if you were to shut the steam outlet valves (and thereby remove the heat sink) then control rod motion would have no effect on temperature, except insofar as it reduces heat generation. To cool the core from there you would need to remove the heat already present (which control rods do not do). In normal operation the heat sink is always available so it's only of theoretical concern but there is a difference between "cooling" and "temperature regulation".
Obviously that's not their main function in a self-regulating reactor, but not all reactors were self-regulating which is what I was contrasting against. In a Chernobyl-type reactor, the control rods were the only thing preventing a run away reaction.
Well although the RBMK reactor used at Chernobyl is quite different in design than standard western nuclear reactors the control rods on that plant were not strictly to "prevent a run away reaction" but actually did quite a few things, including selecting power output and shaping core neutron distribution. That design was not self-regulating on temperature though, that is true. (Indeed, rising power would tend to cause power to increase further). However reactors that do not lower power after an increase in temperature have typically been the exception rather than the rule. One other thing to note is that the RBMK used in Chernobyl was the only nuclear reactor in the world whose emergency shutdown system would initially cause a rise in reactor power, which lead to a prompt critical situation and disaster in this case...
It can't meltdown. You bury it for security and to shield from gamma. If this thing is emiting neutrons then they better not bury it but shield it.
Of course it's emitting neutrons, how do you think nuclear fission works?;)
Just like you bury it to shield from gamma, you bury it to shield from neutrons. If they're really worried about neutrons they can simply put a lot of water around it (water is an extraordinarily good neutron shield).
Reprocessing was already mentioned, but there's also simply distilling the uranium out of sea water. The Japanese already can do it for about $150/kg which seems reasonable. From there we can start using reactors that can burn U-238 instead of U-235. From there we can start using thorium-fueled reactors (and thorium itself can be obtained from sea water). And that's just techniques we already know about, so I don't see why so many people get worked up over proven uranium reserves.
Besides, it's not like we're talking about ripping out wind, hydro, and solar, what we need to be talking about is replacing fossil-fueled plants that provide baseload power. If solar panels on your roof are enough to power your home then great, go solar.
The modern way to prevent this is with naturally self-regulating reactors (as opposed to say relying on control rods to cool the reactor down)
Control rods do not "cool the reactor down". The control the nuclear chain reaction.
For instance in the standard pressurized water reactor commonly used the reaction is completely "self-regulating". If temperature gets too high then power goes down, if temperature drops too low then power goes up to compensate. What control rods do in this type of reactor is to control the temperature that is maintained by the reactor.
Thanks to the magic of decay heat it is possible for a pressurized water reactor to meltdown due to loss of cooling even if the nuclear reactor were to be terminated immediately (by scramming control rods) once flow was lost. I'm not familar with the reactor type they're proposing but there are nuclear reactor designs which cannot meltdown so I don't doubt that it could be done.
The real irony is the idiot that wrote the original paper this stuff is based on (look on ornl if you really want to read it) did not consider gravity. Pollution controls were modelled as a black box that let a certain percentage of everything through. Real pollution controls even remove gasses such as nitrogen and sulphur oxides - what do you think happens to the heavy metals? They end up in the ash dam.
And where does this "slightly radioactive" fly ash end up again?
Better yet I'll do you one better and point you to a USGS study which doesn't even try to answer the question about how much fly ash escapes to atmosphere (a small amount with scrubbers but still non-zero). The result is that even the radioactivity put out by coal plants is not a concern. And this is the coal plant radioactive output which is higher than a nuclear plant.
The fuel can be recycled/reprocessed if not for idiotic laws put in place by ex-Presidents (Jimmy Carter, I'm looking squarely at you).
Ironically President Carter, as a Navy nuclear submarine officer, was probably more knowledgeable about nuclear engineering than anyone in the White House not specifically hired to be an expert on that field.
At TMI about half the core melted and formed a puddle at the bottom of the pressure vessel. Even though they eventually pulled their heads out of their asses and saved the day, that is most definitely an "issue".
The "saving the day" was way after the meltdown. The big concern was the hydrogen bubble formed in the reactor vessel by the reaction between steam and the much hotter than normal Zircaloy fuel cladding. The problem was the risk of the hydrogen causing an explosion that would rupture the vessel.
The meltdown was a concern from the regard of waste handling (as you can't simply pull the fuel cells out of the core like for a normal refueling) and due to the risk of destroying the first layer of containment (the reactor vessel). Even if the melting core material had ruptured the vessel however, that's why reactors in Western nations have a containment vessel to hold the contaminated material (and keep radiation levels outside the containment vessel at background levels).
Keep in mind that TMI-2 was scrammed the entire time the core was melting down -- this was not a runaway nuclear reaction, this was a loss of core cooling (a nuclear core will generate "decay heat" for some time after it is shutdown). So a meltdown is not a concern for radiation generation per se but rather for nuclear plant integrity.
Are nuclear meltdowns an issue? Of course they are -- they wreck a tremendously expensive nuclear core and the cleanup is it itself even more expensive than normal. But it is nowhere near the same league as Chernobyl (which violently blew up due to managing to achieve "prompt criticality", which is the criticality you want to avoid).
I thought as KDE eV president he was the man responsible. I stand corrected. You are to blame.:-)
The KDE e.V. is a non-profit organization which is intended to handle legal and financial matters for the KDE project. So it has a lot to do with KDE but one thing it does not do is dictate the coding done or the direction the project takes. Which is just as well as many KDE contributions are not KDE e.V. members
KDE is my favorite desktop, and I think you're doing great work. I don't take issue with any of that. I just take issue with the release cycle/version numbering. I would not have released a 4.0 without the KDE killer app - KOffice - ported and ready to go. Did MS release Win95 separate from Office? No. What good is a platform release if none of the major apps are ready? Why upgrade?
Well I wouldn't say *none* were ready.:) But yes, before KOffice and for example KDE PIM (the "killer app" for a lot of people) could be ported there had to be libraries to develop on. Even right before we released 4.0 we were debating internally on whether or not it was a good idea based on the status of the applications and libraries. In the end I think the fact that only released software actually gets used (and therefore tested) won the day. We didn't release a bomb with known show stoppers and I know it was put somewhere that Plasma had some changes yet to go, but it was important to at least release something once we had something that we could release.
Think about it this way, with the release of 4.0 we got *tons* of user feedback, mostly from bleeding-edges users who don't have the time or inclination to manually build betas or release candidates. There was a corresponding large increase in code quality from 4.0 to 4.0.1 (and on to 4.0.4). In addition since the number of people routinely using 4.0 went up after the release we got a lot of feedback about where to go as far as features are concerned and right now the 4.0 to 4.1 leap is looking like one of the most impressive minor version bumps in the time I've been using and working on KDE.
Had we not released KDE 4.0 then at this point we might just be getting to a 4.0.2 quality and 4.1 would still be a ways off yet. I know people are annoyed when they install shiny new 4.0.4 and it's missing stuff they liked in 3.5 but if KDE holds onto its code forever then it risks becoming completely irrelevant. And that's all we did, a release, we didn't make people use it, we didn't put things into the release notes that didn't actually exist, and although based on the feedback we managed to oversell 4.0 that was not our intention.
I hope you understand that my interest is just in KDE succeeding.
I appreciate that, I'm just trying to stick up for Aaron when he receives undeserved criticism. I understand that he is in many ways the public face of KDE but it's still a project whose path is dictated by where the development takes it. Aaron leads by example with Plasma but there is much much more to KDE 4 than just a new taskbar and widgets.
Protip: If you're married/in a relationship then attach a "Picture Frame" plasmoid of your significant other to your desktop. It's in the background so it won't interfere with your work but when the desktop is visible so is the picture which has scored me major brownie points with my wife at least.;)
Gnome's answer is to limit features. Ark's answer is to give you tons of dialog windows. Ideally, the options should exist, but not get in the way.
Well we certainly agree here. Just don't mistake a missing feature as being designed out because we feel users are too dumb. Not everything could get ported over in time and new features only get added to a 4.x, not a 4.x.y. so yes, it may take a long time before enough features are in KDE 4 as compared to KDE 3.5 for you. But every person is different, many are happy with KDE 4 at the 4.1 point.
Also a recent comment of his was that non-coders on the whole shouldn't be allowed to comment on design issues.
Well this is not going to make it feel any better but those who do not have experience coding often do not understand why their proposed design change does not or cannot work. Not always, but if you're good enough to design it you're typically good enough to code it. Code is just transferring a design into a language syntax. Designing it in the first place to work correctly (or not...;) is hard.
He also repeatedly said that if you don't read the code, you can't understand the UI. That itself is a problem.
Again, this is probably actually true. Of course you can *see* the UI and point out what sucks about it but sometimes a "trivial" UI change involves a large code change. This is easier to see if you understand how the UI is actually formed from the code in question (i.e. Containments, Applets, Activities, etc. in Plasma-land).
Frankly, end users should be able to pick things up and learn them intuitively. Suggesting that if you don't read the source code, you can't understand the project means there is a serious usability issue.
Sure, but there's also the type of user (and I don't know if this is true in the case you're talking about but bear with me) that does something to the effect of:
User: Hey I noticed this is going on and it sucks, fix it!
Dev: One of:
Yeah, that sucks but it is fixed/will be fixed.
Yeah, that sucks, but not as much as these other bugs I'm working on.
Yeah, that sucks and I'm interested in fixing it but not sure how without breaking foo.
Yeah, that sucks but not enough for me to actually work on it, but patches are accepted.
No it doesn't -> WONTFIX.
User: Why don't you just do something like integrate the frobnitz?
Dev: Because it doesn't work like that.
User: No seriously, just integrate here and you're done.
Dev: No you don't get it. The code does not work like that. It cannot work because of reason foo
Now most bug reports we get are good reports and if the dev is actually here to work on it even get resolved to everyone's satisfaction. But we do get reports like these and when it turns into a pissing match between the user and the developer politeness is usually the first thing to go out the window. I've seen Aaron be ganged up on by multiple users in this fashion and it's really disheartening to see as a developer.
Hey, sometimes the developer is even wrong and it can be implemented somehow but that typically happens with a patch (oh, maybe it does work...), which you're not going to get from the same developers by pissing in his Cheerios and acting like a jerk. And in the end (at least in KDE) those who actually do the work get to decide so if Aaron is holding off on changing something because no one has presented a satisfactory technical solution (i.e. no "evil hacks" for bug fixes) then that's how it'll be.
With the way Aaron is running the show, every one will have to wait for 4.5 for it to be as good as 3.5.
snip
Aaron is a hell of a developer, but he is no project manager. He can't see the forest through the trees. Anyone who is in charge of a project like he is should not be coding.
Aaron is not in charge of KDE. No one person is anyways but although Aaron is a core developer he does not run KDE or choose its direction.
What he does do is a lot of interaction with the press and presentations at events and such so in that regard he has acted as the face of KDE in person.
He also maintains the Plasma program (he does not run the whole show though, there's more people than just him working on Plasma). Many people see it as the "face" of KDE 4 in that it is the most-prominent GUI in KDE.
But he does not choose when we release, what goes in KDE, who works on what, or any of that. KDE has its own Release Team for handling releases (and the Release Team chose to delay 4.0 for 2 months and then after the final RC series to release). Aaron certainly puts in a lot of work to KDE but even if you think the release was a disaster he's not the one to blame. You can blame me if you want, I argued for releasing 4.0 after the first delay in addition to Aaron.;)
First, I believe the development team should have kept it in Beta until it was feature-complete. Feature complete, in my mind, is at minimum the feature set of 3.x. It shouldn't even be a release candidate until "done" and stable.
Hey guys, remember the good old days when open source projects released early and often? Yeah, me neither, highly overrated.
Or in other words, you seem to imply that if KDE 4 was ready to go with two features missing from a KDE 3 program that no one used that we shouldn't even have released a beta until that were done. lol, keep dreaming.
Second, distros should avoid including immature projects like KDE 4 until they *are* feature complete and stable. Yeah, Kubuntu, I'm looking at you!
Hopefully, the Gnome folks (and Ubuntu) will wait until everything's ready for prime time before releasing 3.0
Well yes I think we can all agree that distros should not ship buggy and incomplete code. However KDE 4 is to the point where the features it provides that KDE 3 lacks may outweigh the features KDE 3 has that KDE 4 lacks so that doesn't really make it an open-and-shut case.
Some people suggested removing the animation, which was a problem because it interfered with maximized windows, and he said no.
The "cashew" would cover up a window whether it's animated or not.:P
Some people suggested allowing people to move or relocate the cashew because it interfered with panels at the top, and he said no.
Not according to this email. Looks to me is that Aaron disagrees with the various methods of removing the cashew that have been proposed so far, and that ways to do so that don't suck haven't been proposed in time for KDE 4.1.
Some people suggested having the cashew disappear when the panel is locked, and he said no.
The panel cashew does disappear when the panel is locked but locking the widgets onto the desktop doesn't get rid of other activities. The way I would think to do that is to have the cashew disappear automatically if the one and only activity has its widgets locked but I don't care enough (I mean seriously, a cashew?) to submit a patch.
The worst thing is he repeatedly said everyone was too stupid to understand his design, which he had no intention of explaining. He said users can't comment on design or UI issues. That is a problem.
In all fairness I think this happened after like the third time he tried to explain the same thing and got the same comments back. You can only answer the same question to X number of different people before you too turn into an asshole.;)
And besides (this came up later I think) I'm pretty sure the exact perjorative term used was not "stupid" but the email thread gives me emotional baggage so I'm not going to dig it up to double-check.
Anyways KDE appreciates and needs user feedback but what we don't need are personal attacks on our developers from users, which is what led to Aaron-hates-assholes-ivus. Really KDE the project kind of let Aaron down on this because he eventually came to receive quite virulent attacks even about software he doesn't write or maintain just because he's the highest profile KDE developer and no one stepped in to get it from getting out of hand.
Yet no one knows what the long term design plans for Plasma are. The users keep getting surprised, and they feel that Plasma over-promised and under-delivered.
On top of that you have Aaron Segio now suggesting that users should have less control over configuration, fewer choices, and saying that end users are dumb. He also has suggested repeatedly lately that if you're not a coder, then you can't comment on UI issues.
Why don't you ask the Plasma developer*s* (i.e. more than just Aaron)? In addition the KDE feature plans are linked to from the front page of the KDE TechBase. For things not covered there you could add Planet KDE to your news reader or subscribe to the panel-devel mailing list. Want to see all commits made just to plasma? Use the KDE commit filter.
As far as Aaron he's been under a constant heap of criticism lately because Plasma in KDE 4 is not *exactly like* kicker+kdesktop in KDE 3 so perhaps you can excuse him for being irritable. Perhaps you have examples that are not taken out of context however, instead of just claiming that he hates users? On that note was there an announcement that KDE made that you felt over-promised what Plasma would do? If that's happened we at KDE need to get that rectified.
Gnome already has a few of those problems (removing choice, treating users like they're dumb)
Have you ever thought that taking the trouble to make a program easier to use doesn't necessarily imply that the user is dumb? I'd respond to your specific comment except that you have mentioned none.
For corporate environments, or people who can't be troubled to configure things, they just want working defaults and simplicity. That isn't a flame, but rather the way things are.
A system that just works and is simple to use? Oh heavens, no! If GNOME has already achieved that (I haven't used it in awhile) then that is something to be congratulated for. Defaults that work are a good idea in general and are separate from features. Adding more checkboxes doesn't make a program more powerful.
Since you're requesting input, my own personal pet peeve: when I select Detail View in Konq (indeed, in ANY file manager), I expect it to stick (as View settings do in Windows Explorer). But when I start a new session, it's back to Icon view (and has forgotten window size and position too), causing me to think evil thoughts at the developer.
I just tried it (in KDE 4.about-to-be-1) and it works fine. Better yet Konq and Dolphin both respect it. You *do* have to set it in the Dolphin Settings though (you can also find it in Konqueror somewhere in File Management).
Only catch is that I don't think window position or size is saved though maybe there's some KWin trickery that could help. From what I understand GNOME's Nautilus file manager is supposed to retain size and position in its "spatial" mode but spatial has lots of things I don't like so I haven't tried it in awhile.
Slashdot Mirror
I'd say if it takes you two stable releases to implement very basic functionality like working keyboard shortcuts, then you suffer from a lack of manpower.
Don't get me wrong -- "We're always hiring." :)
Keyboard shortcuts have worked the whole time (at least for me). Working global keyboard shortcuts, not so much (at least if we're talking about multimedia keys in my case). Somehow KWin's global shortcuts work so in the end I don't notice but Alt-F2 has worked since KDE 4.0 so maybe I'm just not experiencing some long standing bug which you're hitting. :(
It's also hard to believe you can look at the kde4 release announcement http://www.kde.org/announcements/4.0/ and not see the problem. What needed to be explained on that page was that KDE4.0 was not ready for everyday use.
"KDE 4.0 is the innovative Free Software desktop containing lots of applications for every day use as well as for specific purposes. Plasma is a new desktop shell developed for KDE 4, providing an intuitive interface to interact with the desktop and applications..."
Fair enough (although I'd claim beta quality as opposed to alpha -- based on using the desktop the week leading up to tagging).
What bothers me though the numbering system. KDE 4.0 is a major update. 4.1 is a semi-fix update and etc.
Can't they just go to 4.1.1+ until they fixed the underlining issues with 4.0 before they can declare 4.2 is ready?
The 4.x.y is numbered like this:
So the 4.2 release will obviously include bugfixes, but it will also be the first release with new features since 4.1.
... but with enough resources, I think you could have reasonably expected to conduct use-case oriented productivity test and a feature count on KDE 3.5 vs. GNOME, and be reasonably confident of KDE coming out on top back then.
Well if anything we would have compared KDE 3.5 vs. 4.0. I know that our respective user bases are quite enamored of their particular desktop but we really don't lose sleep at night just because someone uses GNOME. We're not trying to poach users from a different DE, we're trying to make the best desktop environment. As I already mentioned everyone has their own "best". We hope lots of people will enjoy KDE 4 as it evolves but we neither expect nor demand that everyone likes it better than GNOME/XFCE/Mac/Windows/etc.
And to more directly answer your point: bwahahaha, no, we don't really have tons of resources to do "feature counts" and use-case productivity tests.
Usability analysts like Celeste Lyn Paul do a good job of usability testing and we can definitely use more of the same, but we don't exactly have a huge budget either so for now we rely on volunteer effort.
I'll be surprised if that's the case by the time 4.5 gets here.
I can't (be bothered) because what you see as devs being flamed is what I see as concerned users/developers voices being rejected on the basis that they're flaming.
Well being flamed is being flamed. I've certainly seen people bring up points or features that they think are important without flaming. Typically they get asked to file it in bugs.kde.org, or a developer explains why they think it is a bad idea.
Sometimes it happens that a user will come along and be the tenth person to ask for something that has already been discussed to death on the mailing list. I understand that most people don't have the time to do the kind of searching of mailing list archives required to see if the topic has already been mentioned or not. But it is human nature that people get testy when they hear the same answered point time and time again. Plain obstinacy? Perhaps. But typically unimplemented features that are not rejected on their face but simply due to developer interest or time can be implemented if someone is interested enough to provide a patch.
This is no different from any open source project. A developer has a priority queue of X things to do and unless your proposal is important enough to bump something else off it's not going to get worked on.
Some proposals will never make it in because the developer does not want the program to work that way. Especially changes that make the program less usable by default (i.e. please remove this only visible part of Foo's user interface -- although doing so would make it near impossible to configure for all but power-users). Unfortunate, yes but also how pretty much any open source project works.
I'm not claiming 100% niceness by developers but without something to look at I'm not exactly sure what to tell you. :-/
I wasn't comparing to 3.5 here. I was comparing to the de facto standard for FOSS releases, which is to make something reasonably stable and feature complete, and certainly ready for reasonable third-party development and deployment testing, before you tag it as a beta, never mind a .0 release. Yes, KDE PR tried to do damage control when users expected more from 4.0, but it was hardly enough to counteract such a huge step away from the usual release methodologies.
Well this has been discussed to death a million times over as well
This is just pure insanity. I'm a Linux user and I have no qualms about saying so. You are saying, "Well, it's just the initial release. I'm sure it will get better in like *5* more releases". How can you possibly justify that when the vast majority of the people here that say, "Well, Vista will be better with SP1" get flamed.
Well, how much did you pay for KDE 4.0? How much did you pay for Vista? Did KDE take all copies of 3.5.10 off the shelf when 4.0 was released? (Hint: No.)
KDE4 is literally the linux equivalent of Vista. After 5 service packs (and possibly renaming it KDE 5), it might be usable.
No, it's usable now. I'm sorry if it's not usable for the exact same sequence of tasks that 3.5.10 was but then we're not trying to make 3.5.10, we're trying to make something better.
It's a disaster and a lesson to those that would try to re-write good things because, "We know better".
LOL! Do you know how much source code is in KDE 3.5? There's no way we "rewrote" that all.
However, it does provide an interesting principle about how much change you can put into a project. This is actually the second time KDE has dealt with such a large transition (the first being KDE 1 -> 2).
Now with KDE 3.5 -> 4 our developers were able to produce quite a few positive changes to modernize KDE and take the steps necessary to keep it relevant. Yes, there were features that were dropped that still need to be added again, and some things don't work as well as they used to in KDE 3.5.
What were the alternatives? A straight port of 3.5 to Qt 4? If you seriously believe that, where do you think we started from?...
It took a lot of effort to get the 3.5 codebase onto Qt 4. Believe me, I was there. It took ages to get kdesktop to be able to display its background again, and that was hardly the largest of the broken features. And that was just from the porting process!
Any major changes we wanted to be in KDE 4 had to be there (at least architecturally) before KDE 4.0 due to source and binary compatibility concerns.
So what do you do, take a year or two to re-architect, and another year of bugfixing before you release (and meanwhile become completely irrelevant in the Internet age)?
Or do you take a year or two to re-architect, while application developers port what they can in the meantime and then try and quickly start releasing again? You'll (hopefully) stay relevant but the desktop won't be as shiny.
By releasing early we were able to get immediate user feedback. What if three years down the road we released a polished release that no user wanted to use? At least now we know that desktop icons is a REALLY BIG DEAL for lots of people. ;)
By releasing early we were able to keep developers interested. What do you want to do? Create the next generation of KDE, or do maintainence bugfixes on 3.5? You can attract some developers on the basis of Subversion code alone but at the end of the day you need to make releases, especially for application developers.
By releasing early we were also able to maintain relevance. Who on Slashdot hasn't heard of KDE 4 now, one way or the other? =D Although obviously you never want to shortchange your good name, my experience has been that the harshest comments have come from the most uninformed.
I've seen valid complaints about a feature that is missing or doesn't work as well, or how they don't like the way the desktop is handled now, etc. That's all fair enough. But there are also people who complain about KDE 4.0 being tremendously overhyped, that we said it was going to provide world peace, etc. etc. And I don't see why.
I develop for KDE and let me assure you, the 4.0 release was controversial internal to the project as well. We weren't a bunch of developers telling you that we had the best flavored Kool Aid ever, why don't you have a drink? We certainly had developers
Linus is promoting the best option available at the time, without bias. Which is perfectly sane, and valid.
In all fairness, "best" is one of those things that is in the eye of the beholder. When KDE 3.5 was the latest, GNOME was still "the best" for many people.
Basically, KDE has great tech. BUT core developers seem to have some sort of arrogance about listening to the community
Please elaborate, without using mailing list threads where these core developers get flamed endlessly because people don't like something in KDE 4. On the other hand we are always interested in receiving reports of what we could do better (although reasons of "KDE 3.5 did it this way" does not exactly prove the point...)
and some sort of project-deathwish which manifests in a horrible release process,
Horrible?... How so? I ask because the release process is mostly unchanged since KDE 3.5, where apparently it worked well. What do you think has regressed since then?
minor versions that don't work until x.4 or so,
So you're saying that you've had issues for both 4.0 and 4.1 not working until 4.x.4? 4.1 would have been much the same as 4.0.4, with the exception of extra features. I personally did not notice tons of trouble from 4.1 on (although obviously I'm biased ;)
and poor support for non-core developers.
No offense but this is a troll unless you have something in particular that you're talking about. The same mailing lists, API documentation, and support tools are available now as were available for KDE 3.5. In addition we now have a Wiki available instead of the crusty old KDE 2.x material, KDE TechBase, and the number of developers has only been increasing.
For instance, the latest KDE Commit Digest shows commits by 249 developers, up from 231 a year before. If we go back to the last Commit Digest from Derek Kite in October 2005 there were 195 developers. Argue about seasonal effects or whatever all you want but the data doesn't support your argument.
Moreover they've alienated some of the very groups they tried to encourage early in the KDE 4 brainstorming process.
Well there are definitely "alienated groups" but who are you talking about specifically?
Finally, they generally seem to suffer from lack of manpower, which they have never really tried to solve.
Well not only is that not true as I already mentioned, but your latter point is also not true. I know it's easy to blame the shift of focus that we employed in KDE 4 on everything, but the fact of the matter is that it actually brought in quite a few developers as well... We have people working on the art, basic desktop and games, areas which were mostly unmaintained in KDE 3. Things like the KDE TechBase I already mentioned were created as part of making it easy to develop for KDE. Again though, if you have something specifically that you have in mind then say so as developer support is a very high priority for KDE.
If you believed the hype the core devs were spouting, KDE 4 was going well, and no help was needed, until the product actually appeared as a release and everyone saw the real situation.
Here's the announcement about the Development platform release where the library API was declared stable. "With a lot of issues facing KDE hackers before 4.0 is a usable desktop, all work on new features and UI is stopped, and efforts focus on fixing the inevitable, long list of bugs." Where's the hype?
Here's the Plas
And even before QtScript there was KJSEmbed, which has mailing list archives dating back to 2003.
Of course TFA itself pointed out QtScript and how it is used by Amarok...
The odd thing is that this 13-year-old article recaps research (refereed and published in a respected economics journal) 19 years ago.
Does that make sense to someone?
Well the article basically goes over arguments against the test methods used by Dvorak and points out some contrary studies. Then the article author complains that he had already covered said topic 6 years earlier and the myth persisted. That's what the summary is referring to.
If it helps it was in TFA but I'm not convinced that CP/M 86 was really that much superior....
I know that the Slashdot editing has a very low reputation around here but I was pretty interested to see how much work was done on this article writeup. You can see mine at the Firehose entry. The Slashdot editor even went to the trouble of looking up prior Dvorak-related articles (and taking the trouble to notice the article I submitted was 13 years old -- whoops)
Well I'd have to look at the timeline again but the proximate cause was a stuck open primary relief valve attached to the pressurizer steam space which would certainly have dropped pressure far below nominal (although still above atmospheric). I know that eventually the relief valve was blocked but I'm not sure if that happened before or after meltdown commenced.
Either way though you are correct in pointing out that there was essentially no threat to the public which makes the ordered evacuation unnecessary. (Even if you assume a hydrogen bubble it's not like the containment was going anywhere...)
You can try and regulate temperature back down but you must have a heat sink, otherwise no cooling occurs. For instance for a standard pressurized water reactor which is cooled by creating steam, if you were to shut the steam outlet valves (and thereby remove the heat sink) then control rod motion would have no effect on temperature, except insofar as it reduces heat generation. To cool the core from there you would need to remove the heat already present (which control rods do not do). In normal operation the heat sink is always available so it's only of theoretical concern but there is a difference between "cooling" and "temperature regulation".
Well although the RBMK reactor used at Chernobyl is quite different in design than standard western nuclear reactors the control rods on that plant were not strictly to "prevent a run away reaction" but actually did quite a few things, including selecting power output and shaping core neutron distribution. That design was not self-regulating on temperature though, that is true. (Indeed, rising power would tend to cause power to increase further). However reactors that do not lower power after an increase in temperature have typically been the exception rather than the rule. One other thing to note is that the RBMK used in Chernobyl was the only nuclear reactor in the world whose emergency shutdown system would initially cause a rise in reactor power, which lead to a prompt critical situation and disaster in this case...
Of course it's emitting neutrons, how do you think nuclear fission works? ;)
Just like you bury it to shield from gamma, you bury it to shield from neutrons. If they're really worried about neutrons they can simply put a lot of water around it (water is an extraordinarily good neutron shield).
Reprocessing was already mentioned, but there's also simply distilling the uranium out of sea water. The Japanese already can do it for about $150/kg which seems reasonable. From there we can start using reactors that can burn U-238 instead of U-235. From there we can start using thorium-fueled reactors (and thorium itself can be obtained from sea water). And that's just techniques we already know about, so I don't see why so many people get worked up over proven uranium reserves.
Besides, it's not like we're talking about ripping out wind, hydro, and solar, what we need to be talking about is replacing fossil-fueled plants that provide baseload power. If solar panels on your roof are enough to power your home then great, go solar.
Control rods do not "cool the reactor down". The control the nuclear chain reaction.
For instance in the standard pressurized water reactor commonly used the reaction is completely "self-regulating". If temperature gets too high then power goes down, if temperature drops too low then power goes up to compensate. What control rods do in this type of reactor is to control the temperature that is maintained by the reactor.
Thanks to the magic of decay heat it is possible for a pressurized water reactor to meltdown due to loss of cooling even if the nuclear reactor were to be terminated immediately (by scramming control rods) once flow was lost. I'm not familar with the reactor type they're proposing but there are nuclear reactor designs which cannot meltdown so I don't doubt that it could be done.
And where does this "slightly radioactive" fly ash end up again?
Better yet I'll do you one better and point you to a USGS study which doesn't even try to answer the question about how much fly ash escapes to atmosphere (a small amount with scrubbers but still non-zero). The result is that even the radioactivity put out by coal plants is not a concern. And this is the coal plant radioactive output which is higher than a nuclear plant.
Ironically President Carter, as a Navy nuclear submarine officer, was probably more knowledgeable about nuclear engineering than anyone in the White House not specifically hired to be an expert on that field.
The "saving the day" was way after the meltdown. The big concern was the hydrogen bubble formed in the reactor vessel by the reaction between steam and the much hotter than normal Zircaloy fuel cladding. The problem was the risk of the hydrogen causing an explosion that would rupture the vessel.
The meltdown was a concern from the regard of waste handling (as you can't simply pull the fuel cells out of the core like for a normal refueling) and due to the risk of destroying the first layer of containment (the reactor vessel). Even if the melting core material had ruptured the vessel however, that's why reactors in Western nations have a containment vessel to hold the contaminated material (and keep radiation levels outside the containment vessel at background levels).
Keep in mind that TMI-2 was scrammed the entire time the core was melting down -- this was not a runaway nuclear reaction, this was a loss of core cooling (a nuclear core will generate "decay heat" for some time after it is shutdown). So a meltdown is not a concern for radiation generation per se but rather for nuclear plant integrity.
Are nuclear meltdowns an issue? Of course they are -- they wreck a tremendously expensive nuclear core and the cleanup is it itself even more expensive than normal. But it is nowhere near the same league as Chernobyl (which violently blew up due to managing to achieve "prompt criticality", which is the criticality you want to avoid).
I thought as KDE eV president he was the man responsible. I stand corrected. You are to blame. :-)
The KDE e.V. is a non-profit organization which is intended to handle legal and financial matters for the KDE project. So it has a lot to do with KDE but one thing it does not do is dictate the coding done or the direction the project takes. Which is just as well as many KDE contributions are not KDE e.V. members
KDE is my favorite desktop, and I think you're doing great work. I don't take issue with any of that. I just take issue with the release cycle/version numbering. I would not have released a 4.0 without the KDE killer app - KOffice - ported and ready to go. Did MS release Win95 separate from Office? No. What good is a platform release if none of the major apps are ready? Why upgrade?
Well I wouldn't say *none* were ready. :) But yes, before KOffice and for example KDE PIM (the "killer app" for a lot of people) could be ported there had to be libraries to develop on. Even right before we released 4.0 we were debating internally on whether or not it was a good idea based on the status of the applications and libraries. In the end I think the fact that only released software actually gets used (and therefore tested) won the day. We didn't release a bomb with known show stoppers and I know it was put somewhere that Plasma had some changes yet to go, but it was important to at least release something once we had something that we could release.
Think about it this way, with the release of 4.0 we got *tons* of user feedback, mostly from bleeding-edges users who don't have the time or inclination to manually build betas or release candidates. There was a corresponding large increase in code quality from 4.0 to 4.0.1 (and on to 4.0.4). In addition since the number of people routinely using 4.0 went up after the release we got a lot of feedback about where to go as far as features are concerned and right now the 4.0 to 4.1 leap is looking like one of the most impressive minor version bumps in the time I've been using and working on KDE.
Had we not released KDE 4.0 then at this point we might just be getting to a 4.0.2 quality and 4.1 would still be a ways off yet. I know people are annoyed when they install shiny new 4.0.4 and it's missing stuff they liked in 3.5 but if KDE holds onto its code forever then it risks becoming completely irrelevant. And that's all we did, a release, we didn't make people use it, we didn't put things into the release notes that didn't actually exist, and although based on the feedback we managed to oversell 4.0 that was not our intention.
I hope you understand that my interest is just in KDE succeeding.
I appreciate that, I'm just trying to stick up for Aaron when he receives undeserved criticism. I understand that he is in many ways the public face of KDE but it's still a project whose path is dictated by where the development takes it. Aaron leads by example with Plasma but there is much much more to KDE 4 than just a new taskbar and widgets.
Protip: If you're married/in a relationship then attach a "Picture Frame" plasmoid of your significant other to your desktop. It's in the background so it won't interfere with your work but when the desktop is visible so is the picture which has scored me major brownie points with my wife at least. ;)
Gnome's answer is to limit features. Ark's answer is to give you tons of dialog windows. Ideally, the options should exist, but not get in the way.
Well we certainly agree here. Just don't mistake a missing feature as being designed out because we feel users are too dumb. Not everything could get ported over in time and new features only get added to a 4.x, not a 4.x.y. so yes, it may take a long time before enough features are in KDE 4 as compared to KDE 3.5 for you. But every person is different, many are happy with KDE 4 at the 4.1 point.
Also a recent comment of his was that non-coders on the whole shouldn't be allowed to comment on design issues.
Well this is not going to make it feel any better but those who do not have experience coding often do not understand why their proposed design change does not or cannot work. Not always, but if you're good enough to design it you're typically good enough to code it. Code is just transferring a design into a language syntax. Designing it in the first place to work correctly (or not... ;) is hard.
He also repeatedly said that if you don't read the code, you can't understand the UI. That itself is a problem.
Again, this is probably actually true. Of course you can *see* the UI and point out what sucks about it but sometimes a "trivial" UI change involves a large code change. This is easier to see if you understand how the UI is actually formed from the code in question (i.e. Containments, Applets, Activities, etc. in Plasma-land).
Frankly, end users should be able to pick things up and learn them intuitively. Suggesting that if you don't read the source code, you can't understand the project means there is a serious usability issue.
Sure, but there's also the type of user (and I don't know if this is true in the case you're talking about but bear with me) that does something to the effect of:
User: Hey I noticed this is going on and it sucks, fix it!
Dev: One of:
User: Why don't you just do something like integrate the frobnitz?
Dev: Because it doesn't work like that.
User: No seriously, just integrate here and you're done.
Dev: No you don't get it. The code does not work like that. It cannot work because of reason foo
Now most bug reports we get are good reports and if the dev is actually here to work on it even get resolved to everyone's satisfaction. But we do get reports like these and when it turns into a pissing match between the user and the developer politeness is usually the first thing to go out the window. I've seen Aaron be ganged up on by multiple users in this fashion and it's really disheartening to see as a developer.
Hey, sometimes the developer is even wrong and it can be implemented somehow but that typically happens with a patch (oh, maybe it does work...), which you're not going to get from the same developers by pissing in his Cheerios and acting like a jerk. And in the end (at least in KDE) those who actually do the work get to decide so if Aaron is holding off on changing something because no one has presented a satisfactory technical solution (i.e. no "evil hacks" for bug fixes) then that's how it'll be.
With the way Aaron is running the show, every one will have to wait for 4.5 for it to be as good as 3.5.
snip
Aaron is a hell of a developer, but he is no project manager. He can't see the forest through the trees. Anyone who is in charge of a project like he is should not be coding.
Aaron is not in charge of KDE. No one person is anyways but although Aaron is a core developer he does not run KDE or choose its direction.
What he does do is a lot of interaction with the press and presentations at events and such so in that regard he has acted as the face of KDE in person.
He also maintains the Plasma program (he does not run the whole show though, there's more people than just him working on Plasma). Many people see it as the "face" of KDE 4 in that it is the most-prominent GUI in KDE.
But he does not choose when we release, what goes in KDE, who works on what, or any of that. KDE has its own Release Team for handling releases (and the Release Team chose to delay 4.0 for 2 months and then after the final RC series to release). Aaron certainly puts in a lot of work to KDE but even if you think the release was a disaster he's not the one to blame. You can blame me if you want, I argued for releasing 4.0 after the first delay in addition to Aaron. ;)
First, I believe the development team should have kept it in Beta until it was feature-complete. Feature complete, in my mind, is at minimum the feature set of 3.x. It shouldn't even be a release candidate until "done" and stable.
Hey guys, remember the good old days when open source projects released early and often? Yeah, me neither, highly overrated.
Or in other words, you seem to imply that if KDE 4 was ready to go with two features missing from a KDE 3 program that no one used that we shouldn't even have released a beta until that were done. lol, keep dreaming.
Second, distros should avoid including immature projects like KDE 4 until they *are* feature complete and stable. Yeah, Kubuntu, I'm looking at you!
Hopefully, the Gnome folks (and Ubuntu) will wait until everything's ready for prime time before releasing 3.0
Well yes I think we can all agree that distros should not ship buggy and incomplete code. However KDE 4 is to the point where the features it provides that KDE 3 lacks may outweigh the features KDE 3 has that KDE 4 lacks so that doesn't really make it an open-and-shut case.
Some people suggested removing the animation, which was a problem because it interfered with maximized windows, and he said no.
The "cashew" would cover up a window whether it's animated or not. :P
Some people suggested allowing people to move or relocate the cashew because it interfered with panels at the top, and he said no.
Not according to this email. Looks to me is that Aaron disagrees with the various methods of removing the cashew that have been proposed so far, and that ways to do so that don't suck haven't been proposed in time for KDE 4.1.
Some people suggested having the cashew disappear when the panel is locked, and he said no.
The panel cashew does disappear when the panel is locked but locking the widgets onto the desktop doesn't get rid of other activities. The way I would think to do that is to have the cashew disappear automatically if the one and only activity has its widgets locked but I don't care enough (I mean seriously, a cashew?) to submit a patch.
The worst thing is he repeatedly said everyone was too stupid to understand his design, which he had no intention of explaining. He said users can't comment on design or UI issues. That is a problem.
In all fairness I think this happened after like the third time he tried to explain the same thing and got the same comments back. You can only answer the same question to X number of different people before you too turn into an asshole. ;)
And besides (this came up later I think) I'm pretty sure the exact perjorative term used was not "stupid" but the email thread gives me emotional baggage so I'm not going to dig it up to double-check.
Anyways KDE appreciates and needs user feedback but what we don't need are personal attacks on our developers from users, which is what led to Aaron-hates-assholes-ivus. Really KDE the project kind of let Aaron down on this because he eventually came to receive quite virulent attacks even about software he doesn't write or maintain just because he's the highest profile KDE developer and no one stepped in to get it from getting out of hand.
Yet no one knows what the long term design plans for Plasma are. The users keep getting surprised, and they feel that Plasma over-promised and under-delivered.
On top of that you have Aaron Segio now suggesting that users should have less control over configuration, fewer choices, and saying that end users are dumb. He also has suggested repeatedly lately that if you're not a coder, then you can't comment on UI issues.
Why don't you ask the Plasma developer*s* (i.e. more than just Aaron)? In addition the KDE feature plans are linked to from the front page of the KDE TechBase. For things not covered there you could add Planet KDE to your news reader or subscribe to the panel-devel mailing list. Want to see all commits made just to plasma? Use the KDE commit filter.
As far as Aaron he's been under a constant heap of criticism lately because Plasma in KDE 4 is not *exactly like* kicker+kdesktop in KDE 3 so perhaps you can excuse him for being irritable. Perhaps you have examples that are not taken out of context however, instead of just claiming that he hates users? On that note was there an announcement that KDE made that you felt over-promised what Plasma would do? If that's happened we at KDE need to get that rectified.
Gnome already has a few of those problems (removing choice, treating users like they're dumb)
Have you ever thought that taking the trouble to make a program easier to use doesn't necessarily imply that the user is dumb? I'd respond to your specific comment except that you have mentioned none.
For corporate environments, or people who can't be troubled to configure things, they just want working defaults and simplicity. That isn't a flame, but rather the way things are.
A system that just works and is simple to use? Oh heavens, no! If GNOME has already achieved that (I haven't used it in awhile) then that is something to be congratulated for. Defaults that work are a good idea in general and are separate from features. Adding more checkboxes doesn't make a program more powerful.
Since you're requesting input, my own personal pet peeve: when I select Detail View in Konq (indeed, in ANY file manager), I expect it to stick (as View settings do in Windows Explorer). But when I start a new session, it's back to Icon view (and has forgotten window size and position too), causing me to think evil thoughts at the developer.
I just tried it (in KDE 4.about-to-be-1) and it works fine. Better yet Konq and Dolphin both respect it. You *do* have to set it in the Dolphin Settings though (you can also find it in Konqueror somewhere in File Management).
Only catch is that I don't think window position or size is saved though maybe there's some KWin trickery that could help. From what I understand GNOME's Nautilus file manager is supposed to retain size and position in its "spatial" mode but spatial has lots of things I don't like so I haven't tried it in awhile.