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

[Matthew Ayres]

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

Just going to say that the reason *I* haven't asked questions is
because, so far, I haven't had those questions to ask.  I always ask
if I have one ;)

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

Of course this highlights that diagrams (UML, as you say) must be not
only easily accessed, but open to modification.  And of course, that
even you "don't understand how much of the GUI code works" is an
example that central documentation may be worth having.


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

hehe, can't say I blame you there ;)  And I'm not saying, "Everyone,
stop!  You must harken to me immediately!" I'm just suggesting that
people consider adopting this approach at a convenient point.

> 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

As I attempted to express, I believe that documentation creation
should be a collaborative process, rather than that which has been
seen of individuals trying to document everyone else's work.

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

Indeed, I would not fault your understanding and explanation.  What
concerns me is making the same information easily available to all,
without having to pester you all the time ;)

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

Which is one of the reasons that I suggest a pause to document and
reconsider.  Code can always be changed, that's what it's for.  It's
just that, sometimes, it takes a lot of effort!  With all the effort
that clearly goes into KTechLab already, isn't it worth directing some
of that into clarifying functional boundaries?

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

Yes indeed, and so you recognise that it's important.

In another email you said:
> Goals: Whatever you want. (that's how I've been treating it.) It is easy
> to get into the mindset of commercial development where you are working
> for a customer. In open source *YOU* are the customer. So therefore you
> don't have to live by anyone else's goals. Obviously things suffer when
> stability and performance aren't one of your goals. ;) (as is the case
> with the KDE project these days...)

It's a fine philosophy, one close to my heart, but KTechLab is used by
people who specialise in electronics.  These people do not always know
much about how to rewrite their applications!  So, isn't it up to
those who do to make sure that it's useful?  Ah well, this is really a
matter of opinion.

Please don't think that I'm trying to wade in here, putting people
down and suggesting that I am some great prophet of change.  Rather, I
am somewhat overwhelmed by the sheer power of KTechLab!  It's an
amazing piece of software that's clearly had an enormous amount of
talent and skill behind it.  All I'm saying is that, given the stress
there seems to be surrounding efforts to port from KDE3 to KDE4, it
might be worth looking at the underlying issues in a structured way.

And thank you, Alan, for all that you do for this project.