[Ktechlab-devel] changing the data in IDocumentModel

[Julian Bäume]

On Thursday 09 September 2010 16:18:54 Alan Grimes wrote:
> > About 1:
> >   Removing components is useful in the unit tests about the simulator.
> >   The
> > 
> > simulator with minimal features is essentially implemented, but when I
> > want to make tests that place some components/elements in the test-model,
> > I cannot remove them. The next major work with the simulator is to port
> > all the elements to it.
> 
> =\
> 
> And Julian spent all that time on plugins only to leave essential core
> functionality out? I certainly don't want to alienate our only kde4
> expert but at the same time, I'm getting increasingly miffed about this.
> My message here is "FOCUS ON WHAT'S IMPORTANT! RELEASE EARLY!!"

I focused on the parts, I understand good enough, to work on them. Lately I’m 
quiete confident with how everything seems to turn out fine. I have only spent 
minimal amount of my efforts on the model, yet. I just implemented stuff, I 
really needed.

Removing, updating and adding of components to the model was next on my list. 
It’s possible, to move around the components and even the connectors get 
rerouted, but the model isn’t updated. From the GUI point-of-view, most things 
are done (the routing plugin already gets update information about moved 
components), the next step for me was to update the model.

> > About 2:
> >   As I see in the interface, all the methods return QVariantMap values,
> >   and
> > 
> > not references.
> > 
> >   I'd like to modify the model in order to store there the state of the
> > 
> > simulated circuit: voltages and currents in the nodes. As a way of
> > storing this information, I've thought about placing new keys in the
> > QVariantMaps representing the components, with the name being the name
> > of a pin appended with "_v" and "_i". For example, for a resistor with
> > pins "A" and "B", I'd like to add "A_v", "A_i", "B_v" and "B_i" values,
> > each storing the voltage and current for a given pin. Note that we have
> > to agree on the names of the pins, because both the model, and the
> > simulation part needs to use them.
> 
> Obviously, in that example, A_i and B_i should be cross-linked because
> they should always be exactly the same value. (these are called c-branches)
> 
> furthermore, A_v will be connected by wires to other nodes with voltage
> equal to A_v. (these are called cnodes).
> 
> In the latest SVN code, you can mouse-over each of the component pins
> and if it is part of an analog simulation, you'll see the number of the
> node it is associated with.
> 
> Ktechlab 3 does certainly have unresolved design issues with pins. I had
> only recently completed my work with Wire.

After reading an introduction book on PSpice (to get an insight on how others 
would implement that) and your (Alan) explainations in IRC, I now think, I got 
the point, how to implement a model for circuits. And in the past days (or 
even weeks, now), I’ve been thinking about this. I did some scatches on paper 
how to best store this within a QAbstractModel. Besides an abstract interface 
to our data, I think it would make things a lot easier, when we also provide a 
specific one. I think the classes from the KDE 3 version can do the job, but 
I’d like us to review them, before porting. This can then be used internally 
by the simulator, which should make it more easy to implement. I fear using an 
abstract interface to the data will have much overhead  and it would also feel 
more “natural” to program, when working on a model, that is specific to the 
domain. The thing that is called IDocumentModel, now, will then be used by 
other, more high-level features to get data. “Parts-lists” can be done with a 
simple proxy model, then. But the data has to be stored inside the model 
somehow and for the simulation to be effective, this is best done in a way 
that fits to this application. Access to these classes should be provided 
through a CircuitModel interface, though.

I think, I should get some sleep, now, I will try to provide a better version 
of my thoughts, tomorrow. I hope all this makes some sense ;) Any comments are 
welcome.

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/20100910/ed90bfa8/attachment.sig>