On Wed, Nov 4, 2009 at 11:56 PM, P Zoltan <zoltan.pad...@gmail.com> wrote: > On Wed, 04 Nov 2009 06:52:07 +0100, Alan Grimes <agri...@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
I think Qt 4 have a fairly good MDI system, i had a look at it some times ago, it seemed nice. > >> >> 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. :) > > ------------------------------------------------------------------------------ > 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 > -- Richard Rondu Recherche et Developpement IUT de Cachan - Génie Électrique et Informatique Industrielle 2 ------------------------------------------------------------------------------ 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
