[Ktechlab-devel] Time for a clear route forward?

[Martín Marcucci]

I completely agree with Matthew. The project will be more organized
and open to new developers.
Personally, I would like to help, but when I tried to understand the
code, it was a little difficult and big.

I am a programmer and Electronic Engineering student, like I said in a
mail some month ago, It would be good to make thinks and goals a
cleaner.

> Hello all you lovely devs!
>
> I've been using KTechLab on and off for a while and, watching this
> list, am somewhat concerned.  Not least because so few seem to
> understand the code that's been written.  So, as someone not without
> experience in software projects, I decided to add my tuppence worth.
> It may be just that little, of course.
>
> Mainly, I'm wondering whether serious consideration has ever been
> given to full documentation of this project with flow charts and
> what-have you.  The goals of KTechLab are lofty and surely, SURELY, it
> would aide developers old & new to have a central set of documentation
> detailing both the current state and function of the code, classes,
> interfaces etc. as well as where it should be heading.  No?
>
> Before I have seen such suggestions as I am about to make, in other
> projects, be rejected out of hand but I would like to think that in
> such a project as this it would be worth considering deeply.  My
> suggestion is that code modification be put on hold for perhaps a
> month or two (with a clear deadline laid down), while people work
> together to create the documentation to which I allude.
>
> Those who know enough about electronics, as well as those with a good
> grasp on OOP and Good Practice, could brainstorm together and create a
> fully formed set of flowcharts and related documents detailing how the
> system should work.
>
> Those who enjoy examining existing code could simultaneously create
> current-state documentation.
>
> Compare and contrast, solving the engine's issues all at once and
> coding them to match.  Perhaps this would even be a good time to
> separate the simulator components from the display components, so that
> overhaul of the former and porting of the latter to KDE4 could proceed
> at appropriate rates.  Then the GUI need only have a clear set of
> interfaces with the engine, which also opens the doors for specialised
> GUIs in Gnome and other environments.
>
> Please, consider it.
>
> -Matthew Ayres
>
> ------------------------------------------------------------------------------
> 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



--
R. Martin Marcucci    ( MarkU )