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

[Alan Grimes]

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

Yep. =P

Flowcharts are OK for explaining individual methods. But in a large OO
system such as ktechlab, you learn more by looking at UML than
flowcharts. There are a number of types of diagrams within UML ranging
from entity relationship diagrams to even use case analysis where the
diagram shows the interactions of users with the system to accomplish
work. I slept through those classes but Zoltan has demonstrated some
talent in the art.

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

Yes, that is deeply problematic in a lot of places. So I try to help
when I can. (I always idle in the IRC channel...)

> 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 guess what is needed is a scribe to write down the teachings of the
great sage. =P

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

Problem is that, in spite of my efforts to the contrary, many of the
baundaries in ktechlab remain rather fuzzy. =(

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

In that case, those people have a responsibility to get on this list and
lobby for the changes they need. =)

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

Yeah, that might help. I'm completely overwhelmed by the complexities of
 the vast array of new standards and technologies that would have to be
employed in a kde4 port.

I think one useful preparation that can be made still in the KDE3 branch
are these:

1. I think the basic enhancement to Qcanvas
(canvas.h/cpp/canvas_private.h) was the ability to process negative
coordinants. There are a few problems but these aren't really terminal.
Do some research to see if anyone else has done this and whether we can
use that, alternatively figure out what is required to design a new
version that isn't so deeply enmeshed with the QT3 way of doing things,
maybe fork it off as a subproject...

2. Do basic research on MDI systems so that we can move away from the
borrowed KateMDI code. If QT4's (or KDE4's) standardized MDI is
acceptable, outline the changes this would imply to the class hierarchy.
 I don't think it helps us to be carrying around all that code that we
have to rebuild whenever we do a clean build. Yes, it's low maintainence
but it's really not an intrinsic part of what our core product is. Also,
we want a better way of dealing with projects going forward, including
multiple simulations of electrical, programmatic, and even mechanical
simulations, documents, and even gerber files. I'd much rather get that
functionality for free. ;)


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