Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow embedding UI startup logic in the workflow #2137

Open
glopesdev opened this issue Feb 12, 2025 · 2 comments
Open

Allow embedding UI startup logic in the workflow #2137

glopesdev opened this issue Feb 12, 2025 · 2 comments
Labels
proposal Request for a new feature
Milestone

Comments

@glopesdev
Copy link
Member

glopesdev commented Feb 12, 2025

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 glopesdev added the proposal Request for a new feature label Feb 12, 2025
@glopesdev glopesdev added this to the 2.9 milestone Feb 12, 2025
@glopesdev
Copy link
Member Author

glopesdev commented Feb 12, 2025

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
Copy link
Member Author

glopesdev commented Feb 17, 2025

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal Request for a new feature
Projects
None yet
Development

No branches or pull requests

1 participant