Re: [Qucs-devel] Rewriting Qucs-GUI from scratch with Qt5/6

[Ch'Gans <ch...@gn...>]

On 23 April 2017 at 01:17, Felix Salfelder <fe...@sa...> wrote:
> On Sat, Apr 22, 2017 at 09:40:01PM +1200, Ch'Gans wrote:
>> [Reposting as my email was rejected due to attachment size limit]
>> http://pasteboard.co/7iUPAjLjW.png
>
> ideally there is no such thing as a "qucs model" or a "Xyce model" or a
> "gnucap model". if you really need symbols that only work with
> particular simulators you could do that with the dynamic_cast method
> described in the previous mail.

I think we are not talking the same language here. For me a symbol is
just a graphical representation, it doesn't hold any piece of data or
behaviour, and as such a symbol is not bound to a given simulator.
Drawing a resistor symbol on a schematic sheet is orthogonal with
generating the textual representation specific to a simulator.

In my UML-ish diagram, the "librarian domain" is just a bridge pattern
[1], it decouples entities from modeling languages.
Instead of having to write NxM classes you only need to write N+M
classes (where N is the number of entities and M the number of
modeling languages).
Currently the qucs symbols are just a gigantic copy/paste whith a tiny
amount of specific code and lot of boiler plate.

That's why i came with the idea of an XML file to hold the graphical
data and only the graphical data.
This way, painting gets out of the equation, simple!
Then to help with netlist generation, a template based system could be
used, this will remove all the hardcoded 'template' out of the C++
code.
This way, given a 'Resistor' object, a 'Spice' object, a template and
user parameters you can generate whatever is required by the spice
simulation engine.
Swapping the 'Spice' object with a 'Qucs' object is all that is
required to generate whatever will make qucsator happy.

The 'Symbol' object has knowledge of how to draw a resistor symbol, that's all.
The 'Resistor' object has knowledge of what a resistor is (electrical
parameters, I/Os, ...), that's all.
The 'Spice' object has knowledge of how spice works (parameter
binding, I/O binding, syntax, units, ...) that's all.

[1] https://en.wikipedia.org/wiki/Bridge_pattern

>
> generally, that should not be necessary. if and how a simulator
> simulates a particular device should be part of the simulator driver,
> the simulator device library and the symbols used to represent the
> device.

I agree with "simulator driver" and "simulator device library", but
not with "symbols". See above.

>
> start with "resitor" and "capacitor" symbols. obviously these need to be
> presented in different ways to different simulators. but in the end they
> are the same. similarly, verilog-a symbols. these will carry verilog
> model code (or a reference to a file...), which needs to be presented to
> the simulator somehow, in different ways. still they should just be the
> same in the schematic, no matter which simulator you intend to use.

Agree.

>
> currently qucs has 3 simulator backend drivers. these are for qucsator,
> icarus vvp and some HDL thing. these must be cleaned up and put in a
> dictionary together with more to come. note that the current simulator
> driver code is higly and unnecessarily entangled with the gui as well as
> with qt.

Which part of the source code do you refer to by "simulator driver
code"? Could you give me a couple of file names please?

Chris

>
> cheers
> felix