On Friday 26 March 2010 19:05:09 P Zoltan wrote:
> Related to commit
> move all simulation related classes
> The simulator will be provided as a plugin. This part still needs to be
> ported and saveral things have to be refactored.
> * strip Component to a bare minimum needed for simulation
> * do actual porting work
> First of all, I wanted to do the same thing ;)
> However, the classes in the components subdirectory and the component
> class is the view / controller for the objects simulated in a circuit. So
> as I've understood, the SVG files will replace the view, and there will be
> one generic controller, for all the classes. This means that all these
> should be removed later.
> The problem is with the logic (digital) classes, where the classes also
> contain the model (generally a very simple one). The models should be
> extracted from the component class, and the rest can be removed.
I'm on that.. I already removed CNItem as a base class and made it a QObject.
And I removed all GUI related methods and attributes from Component. May be,
Component and Element should be merged after cleaning up Component. I will
prepare something and ask Alan to comment on that..
> My question is how should be the Simulator class implemented? It's good
> enough a singleton as it was? The problem becomes tricky when we consider
> the plugin structure... Or should we use come class from ktechlatform?
For now, I would like to change the code as little, as possible. So I'd prefer
using a singleton, again.
Another thing I want to discuss is removing all GPSimProcessor calls and
references from the simulator. I prepared a patch, that does this and without
this, we won't have any PIC support in the simulator, but at least it compiles
for me, now ;) (it doesn't link, because I haven't finished the other classes
in that directory, yet.. ) Is it okay to temporarily remove PIC support and
bring that feature back later?