# Open-Source SPICE Project - Help Wanted (C++, GTKmm)

#### sjgallagher2

Joined Feb 6, 2013
131
Hello all. I've been working on a SPICE program which is open-source written in C++ with GTK (GTKmm). The project is essentially an open-source LTSpice-like program, ideally with compatibility with other SPICE programs. To-date, I've been working (on and off) about 2 years on the project, but I've also been learning about software design in that time so the project has been rewritten a few times. I've been very lax with the git so far, so the README is bare-bones and there's no information about e.g. building and dependencies. It's just been a pet-project of mine.

Here's a screenshot I just took:

The code which generated this view at the schematic-level (for testing):
C++:
            std::shared_ptr<SchematicSheet> sheet = _schem->get_active_sheet();
sheet->get_element_list()->find_element(res1name)->rotate90();
sheet->remove_element("V0");

std::string spicelines = _schem->get_spice_lines();
std::cout << spicelines;
The generated netlist is then (from std out):
C0 2 3 C
C1 3 0 C
C2 3 0 C
R0 2 1 R

So you can see a few things going on here. First, there was a voltage source, and it was then removed. Second, all elements are added through a SchematicSheet object, which is owned by a Schematic object within a Workspace. Adding an element involves simply giving a file path (I used absolute paths to LTSpice symbol files), then the symbol file is parsed, the objects required are created, the element is autonamed according to its prefix, and connections for the element to wires underneath its ports are updated.

Wires, associated with nodes, can be added, and their connections are also automatically updated, and the node management is hidden from view (node merges, checking for ports like ground, etc have been taken care of).

The viewing environment allows you to pan and zoom like you'd expect, with the mouse position fixed during zooms to allow zooming into a particular location. It's very smooth.

In addition to the drawing environment, there's also the backend stuff, which has an action stack, tool management, and GUI elements, among other things.

The git repository is here: https://github.com/sjgallagher2/GTKSpice
You can see the implemented features and the TODO list there.

So there is still a lot to do. Everything has grown fairly significantly in the last few months, up to several tens of source files, which is larger than any project I've yet been a part of. As well, the program rests on the core which I've been writing, but considering my inexperience with such large projects, things can get shakey. (I once had to remove many Singleton classes that I'd used as a crutch to help access to common classes...).

So my usefulness is growing limited. I'm still working on the project actively, but as the project grows so does my ability to manage it on my own.

I'm looking for someone (anyone!) interested in contributing to the project, who has a lot of experience in C/C++ and preferably GTK (it doesn't come up too often though) to work on this project with me. You can reply here, or email me at sjgallagher2@gmail.com. Thanks everyone!

#### Attachments

• 17.4 KB Views: 0

#### sjgallagher2

Joined Feb 6, 2013
131
Q&A:
* Why C++ and GTKmm?
Because I'm familiar with them, and I appreciate the robustness of C++. GTK+ is used in other open-source EDA tools like GSpiceUI, and so I liked that aspect of fitting in with previous work.

* Why not just use QUCS, or KiCAD? Or run LTSpice on Wine? Or GSpiceUI?
I do use QUCS, but with its specialized simulator and unique environment, it's more than necessary. As well, it's not compatible with other SPICE programs, and even QUCS-S (spice4qucs) has limited support for proper SPICE functionality. KiCAD on the other hand is overkill for circuit simulation. It's a project for schematic capture and PCB layout, with simulation tacked on. The goal of this project is to have a lightweight and straightforward SPICE interface. The same goes for the gEDA suite. Those do many things, this software does one thing, and therefore new features can be added with superior flexibility and a familiar LTSpice-like interface. And LTSpice is great, but I don't use Wine, and LTSpice is not open-source. The prospect of having an open-source variant is great, and will certainly drive the "industry" further to develop better tools and to stay competitive. But most importantly, LTSpice isn't open-source.

#### ci139

Joined Jul 11, 2016
1,088
irrelevant : i've attempted my own GUI back in DOS/Win3.1(1) times - but as i tried to set my code be compatible with XT , 80286 and AT and the different graphics cards they had . . . i noticed that i simply can't reach the hw specs. for all of them with enough detail . . . so at some point it just dropped off

the memory - browsers can't handle it , MS can't handle it . . . Adobe Reader and Photoshop can handle it the way better . . . LTSpice can't handle it . . . .
- there are unpredictable hardware resources the future users have (likely upward expandability . . . or then you just can rewrite that part of the code . . . if it's not too tightly system integrated)

you got an interesting project

Last edited:

#### MrAl

Joined Jun 17, 2014
6,949
Hello all. I've been working on a SPICE program which is open-source written in C++ with GTK (GTKmm). The project is essentially an open-source LTSpice-like program, ideally with compatibility with other SPICE programs. To-date, I've been working (on and off) about 2 years on the project, but I've also been learning about software design in that time so the project has been rewritten a few times. I've been very lax with the git so far, so the README is bare-bones and there's no information about e.g. building and dependencies. It's just been a pet-project of mine.

Here's a screenshot I just took:
View attachment 196608

The code which generated this view at the schematic-level (for testing):
C++:
            std::shared_ptr<SchematicSheet> sheet = _schem->get_active_sheet();
sheet->get_element_list()->find_element(res1name)->rotate90();
sheet->remove_element("V0");

std::string spicelines = _schem->get_spice_lines();
std::cout << spicelines;
The generated netlist is then (from std out):
C0 2 3 C
C1 3 0 C
C2 3 0 C
R0 2 1 R

So you can see a few things going on here. First, there was a voltage source, and it was then removed. Second, all elements are added through a SchematicSheet object, which is owned by a Schematic object within a Workspace. Adding an element involves simply giving a file path (I used absolute paths to LTSpice symbol files), then the symbol file is parsed, the objects required are created, the element is autonamed according to its prefix, and connections for the element to wires underneath its ports are updated.

Wires, associated with nodes, can be added, and their connections are also automatically updated, and the node management is hidden from view (node merges, checking for ports like ground, etc have been taken care of).

The viewing environment allows you to pan and zoom like you'd expect, with the mouse position fixed during zooms to allow zooming into a particular location. It's very smooth.

In addition to the drawing environment, there's also the backend stuff, which has an action stack, tool management, and GUI elements, among other things.

The git repository is here: https://github.com/sjgallagher2/GTKSpice
You can see the implemented features and the TODO list there.

So there is still a lot to do. Everything has grown fairly significantly in the last few months, up to several tens of source files, which is larger than any project I've yet been a part of. As well, the program rests on the core which I've been writing, but considering my inexperience with such large projects, things can get shakey. (I once had to remove many Singleton classes that I'd used as a crutch to help access to common classes...).

So my usefulness is growing limited. I'm still working on the project actively, but as the project grows so does my ability to manage it on my own.

I'm looking for someone (anyone!) interested in contributing to the project, who has a lot of experience in C/C++ and preferably GTK (it doesn't come up too often though) to work on this project with me. You can reply here, or email me at sjgallagher2@gmail.com. Thanks everyone!
Hello,

So you are working on a graphical interface to work with an existing command line spice analysis program, is that right?