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. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel