[Ktechlab-devel] Connector.

[P Zoltan]

On Tue, 23 Sep 2008 07:52:49 +0200, Alan Grimes <agrimes at speakeasy.net>  
wrote:

> First, it seems to be doing lots of stuff that I thought Wire was for,
> yet the relationship between Connector and Wire is not obvious at all...
>

  Connector: the Controller and View part of the Model/Controller/View  
concept. It draws itself and responds to user commands (moving, mostly),  
and moves together with the nodes associated with it.

  Wire: the Model of a connector; it's used by the simulator; it knows  
about current and voltage; it has two Pins at its ends.

> It has an obvious relationship to ICN document, -- it draws the
> interconnections... However it also seems to cover the directivity that
> only exists in the flowpart branch of the tree, and it also deals with
> wires that only belong in the EC part of the tree. =\
>
> How does it do all that and still remain relatively (but far from
> completely!) sane...
>

  It can do it becasuse it's full of hacks :P

  Directivity: startNode() and endNode(): these define the direction of the  
connector (but: where is the arrow drawn?)

  EC part: hack by dynamic_cast<> : it tries to cast its ends to ECNode; if  
it succeedes, it creates wires for the ecnodes; ( BUG: one can connect a  
bus to a simple wire) Wires

> Obviously it needs to get smarter, to draw cleaner lines for circuits,
> and there needs to be a more powerful engine that is able to sort out
> and optimize Junction Nodes

  In my opinion Connector class should get dumber; it should do only the  
Controller's job in the design and it should place simple lines to the  
canvas; the line optimisations should be encapsulated in the autorouter  
class.


> What I need now is for UML guy to squint at this for me and see what he
> can discover....
>
  Any questions? :)

> On the other side of the source, I'd like to hear from QT4 guy about
> what to do with Canvas.h, and how to safely re-standardize it. It is
> also important to start putting together a roadmap for setting up the
> new components engine... (the entirety of the existing parts library,
> especially the PIC components, will have to be scrapped and rewritten in
> favor of a runtime database and that will require a whole new engine to
> process the parts...)
>

  On long term that's the correct apporach; is short term I'd like to see a  
some bugfix/maintain releases, to let people know that this project is  
still alive ("release early, release often")

  My plan is something like this:
- split out the code as much as it should be: create new classes, get rid  
of the type() members.
- in the new hierarchies, move code "down", so there should be no dynamic  
casts.
- create clear levels of abstraction


   Zoltan