[Ktechlab-devel] Urgency of KDE4 port. =(

Alan Grimes agrimes at speakeasy.net
Wed Nov 4 05:52:07 UTC 2009


The maintainers of Gentoo released a flash traffic ultimatum the other
day that they were going to be removing KDE3 Real Soon Now. Naturally, I
gave them a good and proper flaming with an arm's length list of
packages for which there are no usable KDE4 equivalents.

However, the problem remains.

I'm too stupid to figure out how to pull the kde4 git archive mentioned
the other day, I really do need help! =(

Hopefully I'll be able to load it and see what it implements, what it
doesn't, and how far off the rails the guy who wrote it was... =(

Sorry...

I don't mean to be insulting just there but I've been seeing a multitude
of spectacularly bad design decisions in a great many packages that I
require daily. I am suffering from diminished features and have had to
spend many hours keeping my system near it's normal bare-minimum
operating level. My continued use of Linux is becoming untenable!!! It's
not much fun knowing you have 4.8 billion instructions per second at
your command with a memory bandwidth better than half a gigabyte per
second when your computer is far too slow to let you type at the speed
you want to (for god's sake!!!)

In this case, skimming the code in GIT, I noticed that the person doing
the porting was not just converting base classes and stuff but making
fairly deep design decisions with regards to how components, and even
the core of the engine, will be treated. This is most distressing to me
because this is exactly where all those other cursed projects went
wrong. They were faced with major UI changes and decided to implement a
great many highly experimental changes to the core of their application
as well. They did this even at the cost of many valuable features,
almost all the performance gains of years of tweaking the old design,
and introduced so many bugs that the new versions crash very quickly if
they even work at all on the user's machine.

I'm looking at some code for "plugins/passive/... and can only conclude
that the author simply doesn't understand much about electronics, and
especially how they are handled in ktechlab. There are only two basic
types of *components*; logic and non-logic. There are also three types
of elements: linear, reactive, and nonlinear (active). The resistor,
being one of the most basic of all components, should always be
built-in. It is very reasonable that a plug-in might inherit the basic
resistor and add features such as heat dissipation, power limitations,
and parasitic features and several display options, but the basic
resistor should always be built-in.

The key to avoiding these mistakes is to maintain strict discipline. Do
NOTHING besides what is absolutely required to complete the port.
Acknowledging that there are an above-par number of hacks and kludges in
ktechlab that will need to be addressed before any port can be
considered successful (ie, a move to a more standard MDI system).

It is well acknowledged that the component library does need a major
upgrade, however this is NOT the time to do it!!! I have done much over
the past several weeks to try to separate the actual meat of the program
from dependencies on QT or KDE. (as well as many structural
improvements) I hope this work can be re-combined with a new version
that will distinguish itself from all other KDE packages, and even the
X-org server itself by performing no worse than the KDE3 version.

I acknowledge that part of this is my fault. I had been hiding behind my
 ignorance and failing to take my responsibility as a project manager to
make sure that the KDE4 port is handled in such a way that I will be
satisfied with the outcome.

(It's too easy to get carried away and type too much on a dvorak
keyboard. =P)

-- 
New president: Here we go again...
Chemistry.com: A total rip-off.
Powers are not rights.





More information about the Ktechlab-devel mailing list