Skip to content

fix: apply selected to the scene-graph node and seed tree rows from node state - #67

Merged
LKasianAnsys merged 4 commits into
mainfrom
fix/tree-row-state-ownership
Sep 4, 2026
Merged

LKasianAnsys merged 4 commits into
mainfrom
fix/tree-row-state-ownership

Conversation

@LKasianAnsys

@LKasianAnsys LKasianAnsys commented Sep 3, 2026 •

Copy link
Copy Markdown
Collaborator

Issue

Addresses #18

Context

The source of truth of the 'visible' and 'selected' per-part properties is the server (after #18), and we expect that they are preserved across browser refresh and that they are sourced as expected on a load_state.

3 bugs: On main, we see the following bugs with the 'selected' and 'visible' per-part properties.

  1. When a part is selected in the browser, it is no longer selected when the browser refreshes.
    • This is reflected in the VisorPartState on the client: when the part is selected, the VisorPartState displays _selected: true, but on a refresh, the new VisorPartState shows _selected: false. So the actual 'selected' property doesn't make it across a refresh.
  2. When a part is set to invisible on the client, after a refresh, the mesh remains invisible on the client, but the tree view does not reflect it: the eye icon is set to 'visible'; if I click the part invisibility twice, it turns it back on.
    • The VisorPartProperties 'visible' values are 'false' before and after the refresh, so that is as expected.
  3. When load_state is run on a scene that already has the dataset loaded, the 'visible' and 'selected' both populate correctly. But, when load_state is run on an empty scene (and therefore the load_state API loads the cached dataset before applying the state from disk), the 'selected' property is 'false' and it doesn't show as selected.

The underlying issues of the above predate the changes from #18, but the changes exposed some further symptoms.

This PR fixes the three bugs, so that 'visible' and 'selected' are preserved across browser refresh and on a load_state call.

Description

This pull request enhances the way selection and visibility state are managed and synchronized between scene-graph nodes and the tree view in the Visor frontend. Now, selection and visibility are properties owned by the nodes themselves, and the tree view derives its row states directly from these node properties. This leads to more robust and predictable UI behavior, especially when nodes are modified outside the tree view. Additionally, new tests have been added to verify correct seeding of row state from the underlying nodes.

Improvements to Scene-Graph and Tree Synchronization:

  • The selected property is now applied directly to scene-graph nodes, and tree rows derive their selection state from the node, ensuring consistent selection between the scene and the tree. [1] [2] [3]
  • The tree view now seeds both visibility and selection state from the node when building rows, and synchronizes these states whenever requested, eliminating the need to track selected node IDs separately. [1] [2] [3]

TreeView Interface and Utility Updates:

  • The ITreeViewNode interface has been extended to include a selected property, clarifying the contract for nodes in the tree view.

Testing Enhancements:

  • New tests have been added to ensure that tree rows correctly seed their visibility and selection state from nodes, and to verify that sibling and parent rows behave as expected when node state changes. Utility functions have been updated to support these tests using a no-op renderer. [1] [2] [3] [4]

@github-actions github-actions Bot added fixed bug Something isn't working labels Sep 3, 2026
@LKasianAnsys
LKasianAnsys marked this pull request as ready for review September 3, 2026 17:15
@LKasianAnsys
LKasianAnsys merged commit 88165ac into main Sep 4, 2026
14 checks passed
@LKasianAnsys
LKasianAnsys deleted the fix/tree-row-state-ownership branch September 4, 2026 17:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working fixed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants