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

[P Zoltan]

On Wed, 04 Nov 2009 06:52:07 +0100, Alan Grimes <agrimes at speakeasy.net>  
wrote:

> 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! =(

  Something like git clone should be used...

  For example, a howto is here:
   http://linux.yyz.us/git-howto.html

>
> 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!!!)

  You're doing something wrong :)

>
> 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.

  In something new, there's always a risk. Luckily for ktechlab we have a  
lot of code that nobody dares to touch, because it would break in  
unimaginable ways/locations. So a rewrite about which we know how does it  
work is not an issue.

>
> 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.

  Electronic point of view != programming point of view.

  A design where the core only manages components looks very feasable to  
me. Any component should be threated in equal way.
  For example some audio player apps come with ogg, mp3, ... decoders as  
plugins, even if the program would be useless without them.


>
> The key to avoiding these mistakes is to maintain strict discipline. Do
> NOTHING besides what is absolutely required to complete the port.

  I have a very different view on this. Better write a maintainable  
program, mark it as something experimental, and add all the features from  
the previous version. Until all the features are completed, support the  
old version. If there are no outstanding bugs or missing functionality,  
consider the new version the stable one.

> 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).

Hmm... I should use KDE more, to see what is standard there :D

>
> 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.

  You can't completely remove the KDE dependency. Maybe separate a part of  
the program in a library, that doesn't use Qt or KDE, but the GUI will  
depend on it any way.

>
> 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.

  This sounds like a manager from some company... Open source is more  
about: get involved and let's do it.

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

  If you feel like typing, you might want to give your opinion on the  
issues listed in a previous thread on this list, with "brainstorming" in  
the subject. :)