Samuel Kage wrote:
> Currently I'm running KDE 4.2.1 on Opensuse, which is known for
> making one of the best KDE packages. Even though I'm really sad about
> the stability of KDE these days. For explaining why, i want to
> describe a common use case for me an many many other users.
>
Yes, KDE has a quality problem. I say this as someone that has been
ostracized for advocating that KDE be well designed and well executed.
One has to wonder about some of the issues in KDE-4.2.1 if the person
that did the codding has ever used what he wrote the code for.
The question is why we still have glaring bugs and instability.
It appears to me that in many cases that basic TQM could solve the
problems. For those that don't know what TQM means, it starts with the
philosophy that the way to have a quality product is to build it
correctly rather than build it, inspect it, and fix what is wrong. With
software, this means that the person writing the code should do basic
testing before committing the code.
> The first thing I notice, after booting up, is the quicklauncher-bug which
> makes a very often-used part of the desktop nearly unusable because you cant
> see the small icons.
TQM should address that issue. If the coder (or someone else on that
team) had simply looked at the results of his work and kept at it till
it worked correctly, there would be no problem. The wheel was invented
long ago (the engineering method):
analyze
Design
Implement
Repeat (e.g. analyze the results and continue)
Current design methods use the process on a small scale. This is TQM
and it is more efficient than trying to do it on the whole project.
But, the engineering/development cycle/methodology is the same.
I noticed in the remarks on the dot:
http://dot.kde.org/2009/03/07/kde-commit-digest-15th-february-2009
"To make my point clear: design is what is important. You need
to develop a good design before you write the code."
and this obvious statement was berated. It appears to me that many in
FOSS are using new ethologies (without really understanding them) as
excuses for sloppy work. I agree that *hacking" (writing code without
designing what it is supposed to do first) is not a good method of
software development. The reason is that it is inefficient. It results
in poor code that is buggy and hard to maintain.
Other issues (project wide issues) are more complicated. The current
branching method results in stuff that isn't ready for prime time being
released. What is needed is a methodology that prevents this from
happening. This sounds like a tautology, but it is a very controversial
idea in the KDE development community.
The other question is stability. While some KDE-4 applications are very
stable with only a few small bugs. Plasma is unstable (pre Beta).
Earle r this week, I created a new panel at the left (my left) of the
screen. It was wide so that it could hold the Task Manager and set to
auto hide and grow from the bottom of the screen. It seemed to work
except that there was a problem with the Task Manager not setting the
proper height for the font. Then as I sat there doing nothing, it
changed itself to always visible and growing from the top of the screen.
This is not a bug, this is instability. IMHO, more design work was
needed at the beginning rather than developing a lot of widgets when it
appears that there is a general instability in the library. IAC,
something this unstable should be called Alpha and should not be in a
release.
Do not misunderstand, if and when KDE-4 works, I will like it (yes, I
have some feature requests, don't we all?). Probably more than KDE-3.
What I am saying is that we (well, I'm not part of the we anymore) need
to do a better job and IMHO development methodologies will need some
changes to have a better quality product.
--
JRT
Linux (mostly) From Scratch
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
