XML system components PoC

[ra3xdh]

I have implemented a demo for XML system components. Components could be divided into two big groups:

• Static components: usual active and passive devices. Branch number and appearance always is constant, netlist entry generation only requires to substitute a fields into a pattern.
• Dynamic components: subcircuits, file devices, simulations, etc.

All static components could be represented as an XML code. C++ is not necessary to implement it. The benefits of XML components:

• User don't need to know C++ to add a new static device;
• Don't need to have C++ compiler in a system to add a new set of system components (for example nonfree-devices);
• Reduce compilation time and the C++ codebase size;

The https://github.com/ra3xdh/qucs/tree/XML_comps branch is a proof-of concept of XML components. System XML components are traditional library devices. They operate using the existing LibComp device. System libraries are placed into the QUCS_ROOT/share/qucs/syslibrary and are invisible in the system library manager. But such devices are shown in the Components tab of left-side dock. This branch contain the following modifications:

• Added the netlist pattern entry <Netlist>...</Netlist> for the netlsit pattern. See https://github.com/ra3xdh/qucs/blob/XML_comps/qucs/qucs-lib/syslibrary/RCL.lib#L10 for example. Libcomp::netlist() was modified to extract and handle netlist patterns if presented.
• Qucs GUI looks files at the syslibrary/ subdirectory, parses valid libraries and places found devices into the left dock. The new category with the same name as the library will be created. And components from this library will be placed in it.
• The Component::convertEntry() method convert the old components definition (for C++ components) into the new (Libcomp-based).

EDIT: Build the https://github.com/ra3xdh/qucs/tree/XML_comps branch with CMake and the install Qucs to test this branch. Autotools support probably will be added later. The merging possibility could be considered in 0.0.21 development cycle.

Here is the screenshot of the Qucs main window with the XML system components:

[felix-salfelder]

should be a plugin. like other symbols.

please help with turning the legacy components into plugins first.

[guitorri]

I like the idea of XML. I think we should come up with a proper XML tree to port the existing .sch (which is not proper XML by the way) forward. Use a XML parser and validator (Qt or not) to make sure the schema files are compliant. The XML DOM can become the internal database to handle library/projects/symbols/netlist_formats and used as "the" model for the UI. All you said above still applies, but we would be building on a more standard and structured framework. It would also facilitate data exchange with other projects. This is pretty similar to what the Caneda guys, only that thy did not care to implement the forward compatibility from existing QUCS schematics. That we cannot afford to do.

[felix-salfelder]

do we really need new features now? i think we have a lot of stuff to clean up and fold in.

i am thinking of finishing the symbol cleanup, so we can eventually fold in the nonfree stuff and the vadim components from qucs-S.

just adding more and more code-to-cleanup-later will not facilitate future development.

i am making considerable progress with the loadable components (see #589). with this, we could as well port the caneda approach into a plugin, and will not have to reinvent the wheel. (and not break backwards compatibility, etcpp.)

[ra3xdh]

XML component will be rewritten as a plugin. Closing until #589 will become stable.

[felix-salfelder]

do you have components dumped into XML? could you file a PR with those, maybe in contrib/xml_components. ideally one file per component. then we can talk about loading them.

[ra3xdh]

No, I have no XML component at the current time. I had plans to convert all SPICE-only devices in Qucs-S from C++ to XML, but I haven't started this work. Probably the components from @chgans could be used https://gitlab.com/chgans/QucsLab/tree/master/data/components/spice These components follow the specification of Qucs-S, but they use different XML notation (not Qucs-library, but true XML). Also these components are grouped in a libraries instead of one XML file per component.

[felix-salfelder]

i guess proper XML is not bad. maybe we should start with a/one resistor and see how it fits. don't think it makes sense to import large chunks at this stage. i have not looked at the "file format" yet, tbh.