Add a feature tree representation to the "code" pane

[franknoirot]

What is it

An alternative view of the operations and outputs of the KCL file which shows the scene represented as a traditional "feature tree" found in traditional CAD applications.

How does it help users?

1. Traditional CAD users are put off by the code pane as it exists. Having an alternative "folded" view of their operations makes the interface more familiar.
2. There is currently no good way to edit an operation such as an extrusion other than editing its input parameters directly. This lays the groundwork for "Edit extrude" and others, which could redo the command flow (perhaps skipping to the final step and allowing users to edit the parameters) and edit the parameters for them.

Requirements

• Create a pane view to show all high-level series of operations in dependency order (which is the same as source order) for all parts defined in a KCL scene
• Add this pane view to the KclCodePane as an alternative view, toggled by a button in the pane header
• Add a setting for the default code pane view. When the user clicks this toggle, toggle the setting so it persists
• If there is an error in the KCL, the error icon and tooltip should appear on the operation responsible for it. The feature tree should not break entirely, but persist in a "broken" state.
• Operations may not depend on every operation that came before it, so show dependency lines for those that do, and lines that extend from the operation showing what depends on it.
  • Show named constants in the dependency tree as well, with the same dependency lines to and from
• Separate default geometry (planes) from user operations with a divider
• Add a right-click menu to user operations that lets them:
  • Delete operation
  • Edit sketch (if operation is a sketch)
• Add ability to edit past operations in feature tree by double-clicking them in feature tree #4442

Mock-ups

All mockups are in Figma, but a selection are exported as PNGs here for ease of reading:

Non-requirements, future work

1. Do not need to allow elements' visibility to be toggled. We have no way to hide operations in KCL at the moment, and can add this at a later date
2. Do not need to support drag-and-drop reordering yet, though this is a common ability of traditional CAD feature trees.
3. Add ability to edit constants and non-sketch operation parameters via right-click menu or other method
4. Add ability to suppress features (which is different from hiding them)

Implementation hints

1. Read the operations and declarators from the AST
2. Create a small config that maps AST nodes to FeatureTreeItems
3. icon
4. name
5. label
6. onDoubleClick
7. contextMenuItems (different AST nodes will have different available options)
8. Hook into the existing selection logic to leverage existing flows
9. Don't touch any CodeMirror implementation, and don't remove it from the VDOM when toggling if that messes with any behaviors

Related issues

1. This unblocks The "Sketch" toolbar button should always trigger Start Sketch, never Edit Sketch #4273

[franknoirot]

Note that the implementer of this should handle both operations that have their own named constant declaration, like this:

sketch001 = startSketchOn('XZ')
  |> startProfileAt([0.11, 8.67], %)
  |> angledLine([0, 9.55], %, $rectangleSegmentA001)
  |> angledLine([
       segAng(rectangleSegmentA001) - 90,
       8.67
     ], %, $rectangleSegmentB001)
  |> angledLine([
       segAng(rectangleSegmentA001),
       -segLen(rectangleSegmentA001)
     ], %, $rectangleSegmentC001)
  |> lineTo([profileStartX(%), profileStartY(%)], %)
  |> close(%)
extrude001 = extrude(5, sketch001)

as well as operations that don't and are therefore "unnamed", like this:

extrude001 = startSketchOn('XZ') // This sketch should still show up in the feature tree, maybe as "Unnamed Sketch 1"
  |> startProfileAt([0.11, 8.67], %)
  |> angledLine([0, 9.55], %, $rectangleSegmentA001)
  |> angledLine([
       segAng(rectangleSegmentA001) - 90,
       8.67
     ], %, $rectangleSegmentB001)
  |> angledLine([
       segAng(rectangleSegmentA001),
       -segLen(rectangleSegmentA001)
     ], %, $rectangleSegmentC001)
  |> lineTo([profileStartX(%), profileStartY(%)], %)
  |> close(%)
  |> extrude(5, sketch001)

[franknoirot]

Progress update with some questions for @Irev-Dev mostly I think, although if other team members have ideas I'm all ears:

1. Default planes
   1. Can toggle default plane visibility, but only if you interact with the scene between (can't toggle twice in a row), likely a stale state thing, need to move default plane management into EngineCommandManager
   2. Can't select default planes, need to learn how to do that overriding our "turn off selection" behavior with them.
2. Other geometry
   1. Doesn't make sense to show a hide/show toggle for these items because only the first sketch of an item can be hidden/shown with the object_visible command. We need engine to support hiding/showing sketches independently though
   2. Selection doesn't work as expected with the highlighting and whatnot, not sure why.
   3. Deletion doesn't work for the same reason.
   4. How should we display unnamed items in the feature tree (like an extrude that's a part of a pipe expression from a sketch)?
   5. How do I gather up the EdgeCuts from the same fillet call together into one Feature Tree item?
3. Dependencies
   1. I feel like I'm going to take too long to think through how to do this part properly, and could use some help. I know we have the dependencies encoded in the Artifact graph but I'm not sure how to save them such that when a user selects a feature tree item each of the other items can update their dependency icon accordingly

Video walkthrough

Screenshare.-.2024-11-05.2_25_20.PM-compressed.mp4

[Irev-Dev]

1.i I'm not sure, would have to look at the implementation. You using object_visible yeah?
1.ii The set_selection_filter end point is used for making the default planes hoverable, however the default planes have never been selectable up until now, clicking one of the default planes to start a sketch does not become a persistent selection, it more like transitioning into sketch mode, but the click is important to know which plane for the sketch mode, if that makes sens.
2.i yeah not sure, sounds like the consensus is that it's not to worry about it for the time being anyway.
2.ii Is that because you are making the selections "default" everytime? anyway should be fixed soon by selections refactor.
2.iii makes sense.
2.iv just don't give it a name in the tree, only the correct icon for it's type?
2.v I'll circle back.

[franknoirot]

1.i I'm not sure, would have to look at the implementation. You using object_visible yeah? 1.ii The set_selection_filter end point is used for making the default planes hoverable, however the default planes have never been selectable up until now, clicking one of the default planes to start a sketch does not become a persistent selection, it more like transitioning into sketch mode, but the click is important to know which plane for the sketch mode, if that makes sens.

Yes that makes sense. I think it would be worth including the default planes in the artifact graph, and allowing persistent/non-transitory selection of them. Right now they're being treated too specially and I think having them as just-planes that happen to be always present seems more correct, and will help me not have to create special visibility state tracking behavior.

2.i yeah not sure, sounds like the consensus is that it's not to worry about it for the time being anyway.

👍🏻 works for me

2.ii Is that because you are making the selections "default" everytime? anyway should be fixed soon by selections refactor.

Yeah you're probably right, I'm not 100% sure but that kinda makes sense.

2.iv just don't give it a name in the tree, only the correct icon for it's type?

Hm I'd like to have some text label. I could easily putt Unnamed extrude

2.v I'll circle back.

Maybe I should try a little PR for this behavior, but it is interesting: the need to present all the fillets as one "feature tree" item means that Fillet item is not a 1:1 mapping of the artifact graph, but actually more a representation of the operation of the fillet, that is to say of the AST or KCL code. I'm going to write a few more thoughts on what this thing even is conceptually

[max-mrgrsk]

It’s like a triangle of options:

1. Make it similar to others.
2. Create an exact list representation of our code.
3. Innovate.

1. same like others

in this case we would need following separate panes:

1. feature list (tree)
2. constants / formulas
3. functions

• mixing these elements in a single list is not what the CAD audience would expect
• additionally, we would need to remove the toggle
• display all panes separately (features, constants, functions and xyz planes), because toggling should change the representation, not swap the content.
• arrangement would be tricky, because for example adding the new const in a dedicated pane will probably have to add it into the very beginning of the kcl in order to avoid any conflicts
• for both cases : kcl and feature tree we need a separate pane with bodies. I think the bodies can be extracted out of the last nodes in the artefact graph.

2. list representation of our code

• here, we would literally fold our code pane line by line into a list of features. This aligns with the concept of toggling views but introduces unnatural elements like functions and constants into a traditional feature list
• constants would be scattered across the code, which is unexpected for the CAD audience
• xyz planes would need to be removed since they don’t exist in the code
• functions would have to be represented as folders
• sketch pipes, patterns, and extrudes would also need to be grouped into folders
• we would need an interface to create and edit functions
• arrangement would be super straight forward

3. Innovate

3.1 resilient modelling strategy

This approach focuses on organization and naming. We could divide the pane into chapters: Reference, Core, Features, and Quarantine. And surpress all other features while creating a new one, which is a common modelling practice. Additionally, users could be prompted to name features explicitly, rather than leaving them as generic names like “extrude001,” to make the feature list easier to read and understand.

3.2 node view.

Code often translates better into a node tree (visual programming) than a linear feature list. A feature list typically works for extrudes, revolves, fillets, etc., but code can do so much more. Regardless of the approach we take, we should keep in mind the possibility of adding a node view in the future. It would be beneficial to choose a path now that aligns with this potential direction.

4. Conclusion

I would probably go for the path 1 for starters as pleasing the old CAD community it is our primary target for v1, and divide the pane into 4 foldable subsections: planes, variables, functions and feature list. (splitting them into 4 panes is even better as you might want to have access to them while working in the kcl editor) In this way we will avoid conflicts and the order will more or less reflect the logic of the code. Pipes = Folders