Save only active visualizer dialog settings

[glopesdev]

Summary

Change the structure of the visualizer layout file such that only active visualizers have their dialog settings persisted. If possible, make this assignment robust to most workflow structural changes to improve collaborative and version control experience.

Motivation

The current visualizer layout settings file generates an exact mirror of the workflow file, node by node, even if no visualizer is active in the entire workflow. Furthermore, both editor window state and debugger visualizer state are stored in the same file, side-by-side, although they are almost entirely orthogonal dimensions of information. The current system is excessively redundant, error prone, brittle to even small changes in the workflow file, hard to version control, and overall it has created many sources of confusion and frustration over the years.

With the proposal to rewrite the editor navigation model in #1823 and the rewrite in layout file architecture currently underway in #1956, there is an opportunity to dramatically simplify the current layout file, while opening up new opportunities for more robust layout settings storage.

The core of this proposal is to store only a single flat collection of visualizers which are to be activated when running the workflow. For each visualizer we would store the path to the node used as the source of observable data for the visualizer. By making the path suitably flexible, it might be possible to avoid having to change the layout file altogether for most irrelevant changes in the workflow structure.

Detailed Design

The proposal is to modify the base class VisualizerDialogSettings with a new property to be used as a path to the target workflow operator to be visualized. One outstanding question is what the shape of this path should be:

• At its simplest, the property could be simply the Index of the node. In a way this mirrors the current layout format, except we do not need to recreate the entire workflow structure simply to have the layout settings be assigned to the right place. However, it remains brittle to simple changes in the workflow that cause the node index to change (e.g. insertions and/or deletions).
• On the other end of the spectrum, this property could piggyback on the concept of navigation paths discussed in Proposal for new editor navigation model #1823 where node names could be coupled with counters in such a way that the workflow structure itself could be leveraged to provide robustness to visualizer layout assignment (e.g. if there is only ever one node called ControlPanel then regardless of whichever changes happen to the workflow, its assignment can be preserved).

For example, we could use the following XML syntax:

<DialogSettings Path="ControlPanel" />

To refer to the first node named ControlPanel, or:

<DialogSettings Path="SelectMany#2" />

To allow for name clashes and refer to the second-node named SelectMany.

This format does not afford strict guarantees but might be convenient enough in such an overwhelmingly large number of cases as for it to effectively not matter as much.

Unresolved Questions

• What should the exact format of the navigation path to the node be, and how widespread should this standard be used throughout the core editor architecture?

• The current workflow format allows for non-sanitized group names to be specified (i.e. names with special characters, control characters, etc). How should this be handled in this proposal?

  • One option is to say any nodes with non-standard characters operate as if no name has been specified;
  • Another option is to have a deterministic algorithm to strip / replace any invalid characters from node names for the purposes of generating persistent path string syntax.

[bruno-f-cruz]

It came to mind whilst reading this issue is that it sounds like it would greatly benefit from #2077. By having a point in the debugging process (ie start) where both workflow and visualizers should be simultaneously locked to each other, it may simplify decisions of when to serialize both structures.