-
Notifications
You must be signed in to change notification settings - Fork 28
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
Comments
Moving the discussion originally posted by @bruno-f-cruz in #1955 as it is directly related to embedding UI startup logic:
It somehow feels we have already moved from visualizers being debugging tools once we started using the
In this proposal we suggest adding default state properties to the Nevertheless, we can allow
The goal would be to not require the Apart from the general positioning properties proposed above for the |
Feedback from DCM:
|
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
ShowVisualizer
,LaunchVisualizer
,Visualize
,VisualizerLauncher
Bonsai.Design
Visible
DefaultBounds
DefaultWindowState
(borders?)Title
/Text
(or reuse externalize property forName
from table layout)The text was updated successfully, but these errors were encountered: