"After the recent release KDE 4.1 beta 2 and openSUSE 11 with KDE 4.0.4, some critics have been especially vocal in expressing their displeasure with the KDE 4 user interface paradigms. The debate has grown increasingly caustic as critics and supporters engage in a war of words over the technology. The controversy has escalated to the point where some users are now advocating a fork in order to move forward the old KDE 3.5 UI paradigms. As an observer who has closely studied each new release of KDE 4, I'm convinced that the fork rhetoric is an absurdly unproductive direction for this debate."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-11-10
http://plasma.kde.org/
Aaron have you thought about updating the website for Plasma. I mean I think putting all the information that you post about this all over the internet into one central place would save you and others a lot of time. If you don't have time to update the website is there someone else who does have the time to update the website with sections such as the ultimate goal, look and feel for Plasma and then a section for Plasma in its current condition?
I would do it but I barely know HTML much less anything more advanced like CSS or JavaScript.
Have you thought about removing the Plasma website which is out-of-date by your own admission and just have it link to the Techbase site instead? I think it would help you in the conversations that you have with people.
Member since:
2005-07-06
it does in 4.1.
then every distro release made of kde or gnome ever is a fork. in which case, i'm unconcerned and this shouldn't be a matter for a rash of public news.
As I am well aware. However given your penchant for marking bugs that you do not agree with as "Won't Fix" "
because some of the reports are, well, not going to be addressed. compare to the number of reports that are. the reports that get marked with WONTFIX by me are less probably than 1% of the reports that are either accepted or fixed.
if i implemented every single request without exception, things would be an awful mess.
if you continue to harass me about things that have already been fixed, however, it won't be very impressive. if you say, "but we need $FOO" and i say "$FOO is in 4.1, coming out next month" and then you say "but we don't have $FOO" again, what do you think?
to me these are logistical decisions: which features to implement in which order. they follow from design, but are hardly strategic decisions.
i refuse to accept the request as requested. and i've explained why: the design as put forth in that bug report is quite simply wrong. i've noted in the report (and elsewhere) repeatedly how the design of plasma *actually* works.
if you stop fighting the design and start flowing with it, you'll find you get everything you want, including no cashew.
but i'm not going to let those who are not cognizant of the design screw it up. or do you expect the kernel developers, rdbms developers, apache developers, etc, etc to all implement the algorithms you pitch them for things you evidently aren't familiar with? it's exactly the same thing.
if you communicate with the project (panel-devel at kde dot org) your work could benefit others. up to you, of course, it's your time and patches =)
ok, so let me address the 4.2-4.4 issue directly: if you fork things and take it off in that direction, you're pretty much wasting your effort. had the Suse guys written their panel moving patch in a way that made sense for upstream inclusion, 4.0 would have it. replicate this for every feature you want that we have on our roadmap.
and yes, i explained to them what would make sense for upstream inclusion. instead i ended up writing it from scratch for 4.1. that seems like a waste of their effort and unfortunate for everyone who had to wait an extra 4 months to see it in 4.1.
this is a rather strict definition of "fork", and generally not what is implied by the term.
we do this all the time, yes.
i have no issue with feature branches. but again, this is not what the word "fork" usually refers to.
you do realize that that's what the term "fork" means in f/oss, right? hm.
great. so here's some suggestions on how to do that: work in kde's svn where we can all see what's going on and make it easy to move patches around (e.g. into trunk/). communicate with the project so that we can attempt to work together. there's probably over a dozen active developers working on plasma on a nearly daily basis, so this communication would serve a lot of people.
if you are interested in working in this fashion, then get on panel-devel, we'll hook you up with an svn account and we can get down to hacking.