On Tue, 23 Sep 2008 07:52:49 +0200, Alan Grimes <[EMAIL PROTECTED]>
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
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Ktechlab-devel mailing list
Ktechlab-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
