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

[glopesdev]

Outstanding questions:

• Should we allow closing / opening the visualizer to interact with the underlying observable sequence? For example:
  • Opening the visualizer when the sequence is subscribed to (dynamic opening)
    • Another option this might open is launching multiple dialogs
    • Or alternatively a separate node that materializes visualizers as explicit object instances
  • Closing the visualizer will cancel the source and complete the sequence
    • Or alternatively close the visualizer when the source is cancelled or completed
  • Should options for the above be provided?
    • Even if we do they could be offered as a separate operator
• Should visualizer settings be allowed in ShowVisualizer?
  • If yes:
    • Should visualizer settings be editable in the property grid?
    • How to handle nested mashup settings?
  • If no:
    • Should visualizer settings be disallowed entirely from dialogs shown with ShowVisualizer?
    • Should visualizer settings be persisted elsewhere and merged with local settings in the .bonsai folder at runtime?

[glopesdev]

Feedback from DCM:

• For the first release of this feature, do not allow visualizer settings nor dynamic options
• Do not provide any configuration other than basic window settings. It should behave as an implicit visualizer which is activated on workflow launch

[glopesdev]

Further points for discussion:

• If the operator is not really evaluated at runtime, it may be misleading to name it using a verb, e.g. ShowVisualizer. In principle such a verb should be reserved for the dynamic version of the operator.

• The operator properties can be externalized, but because the operator is not evaluated at runtime, it is meaningless to map values to them at runtime, i.e. it is not possible to compute a form location dynamically. Incidentally this works from the CLI since CLI assigned properties are set at open-time before the visualizers start.

• The static version of the operator is actually a no-op in terms of operator definition. It is not even a sink, since it doesn't even do anything (not even subscribe or cancellation). In fact the only agent who does the action is the editor itself, which looks at the node as an "annotation" and launches the visualizer (the editor, not the node):

  • In this view it might make sense to use the same visual mark as the AnnotationBuilder as the static version more of a declaration of intent, rather than a statement, i.e. much like Attributes in C#.
  • If we go this way, we might want to consider whether the visual mark for the Annotation node should really be the same as the visual mark for other mappings, like PropertyMapping, InputMapping or VisualizerMapping, which do have functional implications.