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

Wed Nov 4 22:10:43 UTC 2009

On Wed, Nov 4, 2009 at 11:56 PM, P Zoltan <zoltan.padrah at gmail.com> wrote:
> 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

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