moin,
okay, here is what I’ve done on this topic. It just shows, how the properties
will be permanently stored to be re-used by our users, later. Of course there
can (and most likely will) be some classes to collect all the information
needed.
Am Donnerstag, 28. Oktober 2010, 23:31:11 schrieb Zoltan Padrah:
> After analyzing the source code of the old simulator, I've come to
> the conclusion that currently the best way to abstract the simulator,
> is to use the following abstraction:
>
> - the cicuit elements should be added as the existing Component subclasses
> - the Circuit itself could be extended to have a list of components
> - the elements (or components) have Pins
> - Pins can be connected with Wires
>
> We need the component level abstaction, becasue some components might
> be formed by have more than one element.
>
> All the above mentioned classes should be models. The controllers
> should be separate classes, I guess.
>
>
> The classes derived from Components can have properties.
Do you consider the Pins also to be "properties" of a component? For most
components, these would be static, but for sub-circuits, they would be dynamic
for instance. So I’d say, Pins are also, like everything else, just another
property of a component. So for most components this will be hard-coded
somewhere but for self-defined components with sub-circuits this will be
created dynacialy from circuit-file (all external-connector items will be
exposed to the user as pins).
> A quiestion
> is, how should be the properties implemented. I see two options here:
> - as traditional C++ properties, with setter and getter methods; the
> property should be set by the controller and it should have associated
> property classes/objects.
> - as propery object associated with each component object. The
> component shows only the list of its properties, and those properties
> can be handled by the controller.
>
> Currently I don't know which way of implementation is better. Any ideas on
> this?
I’ve been thinking about this, lately. I wanted to implement a properties
editor, similar to the one in the KDE3 version. These properties need to be
stored in the circuit files. They are so, now :) (Have a look into a circuit
file and find the <data> nodes as children of <item> nodes.) This way of
storing them is IMHO a good one. I implemented the CircuitModel-class as a
model to represent this information. For now there is nothing special done
about circuits, but these properties will be the first things that should IMHO
go into this. For now, all I did was the IComponentDocumentModel, which is
responsible for storing items, nodes (nodes are pins without parent-items) and
connectors. This can be re-used for FlowCode as is, at the moment. So the
document is a list of item-, connector- and node-elements. In the circuit-
case, another layer is added to all the items. So each item-element has a list
of data-elements as children. This is the case in the circuit-file, now and
will be the case in the CircuitModel, soon. In code this will look like this:
CircuitModel* model; /*get model from somewhere*/
QModelIndex item = model->indexById("some_items_id"); /* I added the
indexById-method to provide in easy way to find anything in the circuit by id
*/
kDebug() << "number of properties for item " << item << ":" << model-
>rowCount(item);
Then you can use all QAbstractItemModel-methods to retrieve and work with the
data or implement convenient methods for that into the model.
I have done all this for the non-electronic properties, now. It seems to work,
for me ;) so it’s possible to move around components and store the changes
into the circuit file. There are some bugs with routing, but I will sort them
out. I added an interface to expose that information to the model. The
controller (in my case the CircuitScene) has a lot of QGraphicsItems on it,
which implement this interface. The main thing is the data() method. It
provides a QVariantMap containing everything that should be stored in the
model. (like coordinates, id, type, all stuff like that) So the CircuitScene
(controller) takes care of creating new components from the QVariant-data of
the model and to update the model with QVariant-data it collects from all the
things "living" in the scene.
For the simulator something similar is needed. You have a controller (call it
Circuit or so) and use the CircuitModel to create Element-instances based on
that data. The Circuit will then start the calculation-process or something
and store the results in the CircuitModel, again. This information doesn’t
need to be stored on disk, so we need to handle them slightly different, but
that‘s not a big deal. The CircuitScene monitors the model for changes and
will update the ComponentItems which are displayed on the CircuitView (or even
somewhere else).
bye then
julian
|