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

[Alan Grimes]

Matthew Ayres wrote:
> 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. 

That's because they lurk for months and months and then complain when
nobody answered the questions they *didn't* ask. =P

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

Zoltan made some efforts in that regards. (UML diagrams are preferred in
OOP). His diagrams helped me find a design problem so therefore I
promptly made changes which invalidated parts of his diagram. This is
only one of the problems... Another is that I don't understand how much
of the GUI code works myself, or much of the code outside of the
electronics code which I am relatively uninterested in.

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

I'm busy trying to earn money these days (and spend it before the
Federal Reserve devalues it...). Therefore I'm not making many changes
right now. Feel free to create whatever documentation you require.
However you are absolutely required to ask me questions before
complaining that I haven't answered them!!! =P

(If you read enough of the great many posts I have sent to this mailing
lists carefully enough you should find a great many answers to questions
about the structure of the code, even if the answer is a bit vague).

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

I've worked on that but there is one major problem with that suggestion.
The code for the inner workings of logic components, as well as some
very problematic code for coloring LEDs is implemented inside of the GUI
classes which are also doing things such as drawing the shape of the
component, laying out pins, etc...

As I mentioned, I have done a great deal to minimize reliance on QT base
and container classes.

-- 
New president: Here we go again...
Chemistry.com: A total rip-off.
Powers are not rights.