Save and load configuration from the GUI

[bparks13]

Currently, configuration parameters can only be supplied one way, at startup, via the launcher's config.json; there is no way to save or load settings from within the running GUI. Users should be able to export the current configuration parameters to a config.json file and load an existing one back into the GUI to restore those settings.

[jonnew]

I feel this should be re-opened: #38 (comment)

[bparks13]

@jonnew You're right that the Bonsai workflow nominally serializes node properties; the problem is that it doesn't apply to the state this GUI is trying to save.

The settings a user changes in the GUI (COM port, enable toggles, file path, trigger mode) don't live in the workflow's externalized node properties. They live in reactive subjects. Using the COM port as an example, the externalized PortName property feeds a BehaviorSubject once at startup, and from then on the ImGui panel pushes new values into that subject. Those runtime values are never written back to the node property; to do so is actually a compile-time error in Bonsai, as the subject would be initialized in reference to itself. So saving the workflow serializes the startup value, not what the user selected while it was running. This is true in the editor too, not just headless. Serializing the graph captures the defaults it launched with, which do not update in real-time.

On top of that, the packaged app runs headless (--no-editor), where there's no save step at all. As Bruno put it earlier today when I asked about this problem: "By definition it doesn't save the workflow since you are not editing code. Similar to running a Python script."

So capturing the current settings means explicitly reading those runtime subject values and saving them to file, which is what the original PR does (granted, that is only when the user clicks the button). It seems redundant at first, but it's an unfortunately necessary wrapper converting the run-time properties into a format the headless launcher can consume. Where we can go from there is to explicitly save the configuration when the visualizer closes, writing to the configuration file that the launcher reads when the script launches the workflow. The launcher already reads a static default config.json and injects each value with -p:Name=value, so the round-trip will become: GUI writes config.json → launcher restores it at startup.

Concretely, WriteSettingsToFile is already generic, and we can hand it CommutatorSettings, FileSettings, etc. and it writes them all into one config.json. The remaining work is on the load side: line up the serialized key names with the externalized property names the launcher targets (Enable → CommutatorEnable, etc.). Below are all of the nodes needed to write the CommutatorSettings to the configuration file:

[jonnew]

We we need to both write our own logic for serialization and then add logic to the workflow to perform deserialization every time we want to do something new. The use of the workflow as our underlying logic is becoming more and more questionable, especially since bypass it half the time (#42, #35).

Lets think harder about how we can have our cake and eat it too.

[bparks13]

@jonnew Here is a proposal for we can move forward without manually rolling our own serialization/deserialization infrastructure.

Bonsai.Sgen

Proposed approach. Adopt Bonsai.Sgen, where we describe the settings once as a JSON Schema; sgen generates the C# settings classes and serialize/deserialize operators. That yields three things from one definition:

• Save/Load from the GUI
  • the Save/Load Config buttons call the generated (de)serializer.
• The same capability inside any workflow
  • SerializeToYaml / DeserializeFromYaml plus file read/write appear as drag-and-drop nodes. Can be wired to automatically save/load configuration files when the workflow closes/opens.
• A single config file as the source of truth shared by the GUI, the workflow, and the launcher.

Configuration files can be saved as either YAML or JSON.

Prototyped locally

• Round-trips the full HardwareSettings tree (Miniscope + Commutator) to/from YAML, runs end-to-end inside Bonsai.
• Existing hardware enums stay the source of truth via sgen's x-sgen-typename, the generated config reuses OpenEphys.Miniscope's GainV4/FrameRateV4/… directly.
• Runtime-only fields stay out of the file. For example Commutator.IsConnected is excluded from the schema and re-added as a runtime-only property, so the file the workflow writes correctly omits it.

Sample saved file

Miniscope:
  LedBrightness: 10
  Focus: -20
  SensorGain: Medium
  FrameRate: Fps15
  LedRespectsDigitalIn: DigitalIn0
Commutator:
  PortName: COM2
  Enable: true
  EnableLed: true

Trade-offs

• The schema becomes the source of truth and the settings records become generated classes. Code impact is small: construction changes from positional to object-initializer; property reads are unchanged.
• Generated classes use reference equality rather than record value-equality
  • Not relied on today, easily restored if ever needed.
• The current file's fault-tolerance (tolerating partial files / preserving unrelated keys) could be re-added in a thin wrapper if we want to keep it.
• Adds one build-time tool (Bonsai.Sgen) + the YamlDotNet dependency, and a "regenerate when the schema changes" step.