Wire and Gate representation

[NogginBops]

This is an issue for discussing the structure for wires and gates.

Should wires and gates be represented in different ways?

• Yes, because the GUI will have to know the difference it will simplify things a lot.

How should wires be represented?

• Wires will be represented as strait line-segments in the GUI. While the backend will have the concept of a subnet, so there atm there is no clear representation for wires there.

How should gates be represented?

• Open question.
• The GUI and backend will have to be synced on the implementations for gates. This means that the drawing code will live in the GUI and the simulation code will live in the backend and they will communicate about these things in some way.

Things to consider are:

• Undo functionality.
• C# x rust interop.
• Speed of execution/simulation.
• Visual representability.
• Being able to save a file and getting the same state back when loaded.
• Subassemblies

[weerox]

It would probably be best to let the backend handle file operations (open and save) and the GUI will pass file paths to the backend.

[NogginBops]

What we have decided to do is have wires and gates be represented separately.

Wires are strait segments that ends in two connections (no connections in the middle). The backend will not be concerned with where wires are connected, but will instead know about the subnets that compose the scene.

We've also decided that the GUI and backend will have to be synced when it comes to gate/component implementations. Meaning that the drawing code for a particular gate will be coded into the GUI while the simulation code will be coded in the backend and the two will communicate about these gates using some kind of id (enum).

Because the gui contains visual information that is important to save to save files we will do the saving on the gui side.

[NogginBops]

Closing this discussion as we have a representation that is working at the moment. We can open a new issue if we want to change anything.