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

[Juan De Vincenzo]

Please try this, I think you should be able to pull the code from this repo:

http://krtek.asta.uni-luebeck.de:8080/git/ktechlab.git/

Also, does anybody know this guy? http://tuxbotix.wordpress.com/

He should really be invited onboard if he is not here yet.

Regards,
Juan

On Wed, Nov 4, 2009 at 11:48 PM, Alan Grimes <agrimes at speakeasy.net> wrote:
> P Zoltan wrote:
>>> 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
>
> Thanks, but the real problem is that I don't know what URL to use as the
> repository location, what path, etc... =( Sourceforge is nice because it
> has instructions for that. =\
>
>>   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.
>
> That doesn't follow. You're just adding to the mess with a bit that you
> understand but everyone else doesn't.
>
> I've been through most of ktechlab's code and I am very willing, eager
> even, to explain what I've learned.
>
>>   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.
>
> This is not the same thing. In this domain, it makes very much sense for
>  the basic circuit elements, and their permutations, to 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.
>
>>   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.
>
> I've put in a vast amount of effort to improve the maintainability of
> ktechlab. Many parts of the program are actually beginning to flirt with
> Good Design(tm). A total rewrite is insane. Experience is showing that
> most people tend to get overconfident in the rewrite and tend to forget
> about problems that had been addressed in the old design and to become
> far far too overambitious in the use of new features that may be
> untested or broken. The quality of the finished product suffers greatly
> for it.
>
>>   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.
>
> Indeed. Much of ktechlab's current magic is in its UI. It will take a
> superbly talented programmer to match what was put in place by the
> project's initial authors.
>
>
> --
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
>