[Ktechlab-devel] Abstraction and properties of components

[Julian Bäume]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/ktechlab-devel/attachments/20101029/2ffbbac3/attachment.sig>