Allow embedding UI startup logic in the workflow

[glopesdev]

Summary

Introduce a new operator for workflows (e.g. ShowVisualizer) which can be used to explicitly mark which visualizers should be launched and/or made available on startup.

Motivation

Application UI startup

The .bonsai.layout files are quite often used in application deployment, as they are currently the only option available to specify the initial visualizer state for the application at startup time. This is crucial in experiment automation where UI needs to launch with the workflow. As first discussed in #1955, further isolating the .bonsai.layout files from the main workflow runs the risk of introducing confusion, especially if we double down on the intent to ignore versioning of these files altogether.

One option to address this drawback is to introduce a new operator for workflows (e.g. ShowVisualizer) and explicitly mark which visualizers should be launched and/or made available on startup. This could also be leveraged as a starting point to avoid confusing environment-dependent visualizer window state (e.g. position and location) with application logic.

Explicitly launched debugger visualizers would continue to save their environment-specific state in the .layout file.

Detailed Design

TBD

Unresolved Questions

• Flesh out details of the new launch visualizer operator
  • Name: ShowVisualizer, LaunchVisualizer, Visualize, VisualizerLauncher
  • Namespace: Bonsai.Design
  • Proposed Properties:
    • Visible
    • DefaultBounds
    • DefaultWindowState (borders?)
    • Title / Text (or reuse externalize property for Name from table layout)

[glopesdev]

Moving the discussion originally posted by @bruno-f-cruz in #1955 as it is directly related to embedding UI startup logic:

I like this (it would also solve #1862 as a bonus :P), but it seems like it would greatly increase the verbosity of the language and, once again, move visualizers away from being debugging tools.

It somehow feels we have already moved from visualizers being debugging tools once we started using the .layout files to "launch" both front-end UI and monitoring visualizers which are required for the workflow to function properly.

I also don't think it would necessarily solve the problem. People would still need a way to create the layouts (in this case add the operators, set their state, move the windows around and save a layout, since the layout is still responsible for keeping the position of the windows for instance).

In this proposal we suggest adding default state properties to the ShowVisualizer node, e.g. bounds and window mode. These should in principle allow the workflow to function without any .layout file at all. They would also be amenable to initialization from the CLI using externalized properties.

Nevertheless, we can allow .layout files to merge with these defaults so that people can slightly tweak and adjust session parameters for their specific local setup and have them persist.

I may be missing something but this creates a situation where the state of the visualizers will still need a layout file by default to regenerate the state (which btw feels a bit weird as now the workflow operator properties depend on the layout file).

The goal would be to not require the .layout file for anything. Since the ShowVisualizer node is placed following a specific node, it can in principle get from the build process which exact visualizer type should be launched.

Apart from the general positioning properties proposed above for the ShowVisualizer node, in principle if we know the visualizer type we could project any extra properties in the property grid to allow direct configuration. Those properties could even be made to be serialized in the workflow using XElement, although I feel that if we are constructing and parameterizing visualizers in the workflow we should probably use the already existing strategies adopted in the GUI and new visualizers package, so we might not even need this at all.

[glopesdev]

Feedback from DCM:

• Consider calling show on subscription (would allow instantiating multiple visualizers) and close window on termination
• Receive a stream of values of DialogTypeVisualizer and call them (to allow dynamic instantiation)
• As a complement, we could also imagine an operator that materializes a visualizer dialog / control without actually launching it