C# x rust interop

[NogginBops]

We want define how C# and rust talk to each other early in the project. This will allow the backend and the frontend to be more independently developed.

This is an issue for discussion on how this should be structured. The current running idea will be continuously updated in this post.

[NogginBops]

One way I've considered is to minimize the amount of entry points and structs that needs to be handled in C# as well as rust.

This would mean having some kind of representation that abstracts away most of the gate specific things into editable properties.

struct Gate {
    Vector2 Position;
    var Orientation;
    // etc. for common properties

    PropertiesList Properties;
}

struct PropertiesList {
    int Length;
    Properties* Props;
}

enum PropertyType {
    Int,
    String,
}

struct Property {
    PropertyType Type;
    byte Value[8]; // This is read differently depending on how 'Type' says it should be read.
}

And then the introp calls would be something like:

Scene* scene = Logic.GetScene();
// Do some stuff...
foreach (Gate gate in scene.Gates)
{
    foreach (Property prop in gate.Properties)
    {
         // Something something
         Logic.SetProperty(prop, value)
    }
}

There would only be a few entrypoints to manage:

public void Init();
public void Exit();

public Scene* GetScene();

public Gate* CreateGate();
public void DeleteGate(); // or DestroyGate
public void UpdateGate(Gate* gate); // Or something else for notifying the backend of changed stuff like position

public void SetProperty(Property* prop);

This doesn't have to represent exactly how the entry points will look but it's meant to get an idea across.

[NogginBops]

During a discussing about the GUI today we realized that we had not considered the case where graphical components change shape and color depending on it's properties. This is something we want to figure out how to do effectively.

At the moment it looks like the c# front-end will have to know how to draw every component individually which is not optimal because the rust and c# code must sync the components they implement. But there doesn't seem to exits any other good solution...

[HalfVoxel]

Many existing logic/circuit board design systems have a separation between the logic and the visualization of a component. The visualization is usually called the footprint and is (simplified) a combination of: drawing + mapping of pin IDs to positions in the drawing. This is a more data-driven approach. The GUI does not necessarily need to know that a particular component is say an AND gate, it just needs to know that it has 3 pins and an associated footprint (svg?).

Just my 5 cents. Maybe you already knew all this, or it might be completely irrelevant, but otherwise it might be a useful point of view.

[NogginBops]

This is fine and will work for normal gates. But there are a handful on gates that change visual representation depending on the properties of the component as well as depending on the input.

For components like the LED Display component in Logisim the properties define the visual size (resolution) of the component and the input wires light up different parts of the component. For that there needs to exist logic somewhere that handles the drawing because there is no practical alternative.

This could be implemented in special cases in the GUI but it would be a lot nicer to not have to. As defining different parts of the same components in different languages basically destroys any feasibility of modding support.

[NogginBops]

We have a communication working. If there are any specifics that need to change we can open up separate issues for those.