Tune the layout from a pane beside the graph - #33
Merged
Conversation
The editor could arrange a graph but not adjust how: the eighteen settings the force-directed layout has were reachable only by recompiling. ktsu.ImGui.NodeEditor 3.26.0 supplies the whole tuning surface as a panel, so this is the wiring rather than another set of sliders that would drift from it. The tuning gets a pane of its own in the side column, under the properties and the generated code, rather than a section inside the properties: it is read while watching the graph move, so it has to be able to be tall while the properties are short, and it must not close itself every time a different node is selected. Its split is remembered between runs like the other two. One flag rather than two for whether the layout runs. This editor stops the simulation by not advancing it, in LayoutRunning, while the panel's own run toggle writes the engine's Enabled - so the panel is shown and written as LayoutRunning and the engine's flag is left on. Otherwise there would be an arrangement in which the graph sits still for a reason the toolbar does not show. The tests cover the wiring rather than the controls, which belong to the library and are covered there: that every group renders, that dragging a slider reaches this graph's own engine rather than a copy of its settings, and that the run toggle is the flag the toolbar holds. Directory.Packages.props moves the six ImGui suite packages 3.25.0 to 3.26.0, which is where the panel arrives. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D2KNUKr1xJPTEdDmeF2tQN
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The editor could arrange a graph but not adjust how. The eighteen settings the force-directed layout has — repulsion, spring strength and rest length, the left-to-right bias, link flattening and untwisting, gravity, overlap clearance, damping and the speed cap — were reachable only by recompiling.
ktsu.ImGui.NodeEditor 3.26.0 supplies the whole tuning surface as a panel, grouped by force and captioned on hover, so this PR is the wiring rather than another set of sliders that would drift from it.
What changed
AstGraphEditor.DrawLayoutSettings(Vector2)— mirrors the existingDrawInspector(Vector2): the editor supplies the panel, the app places it. DrawsPhysicsSettingsPanel.DrawagainstGraph.Engine, then its diagnostics (energy, settled, substeps) under a separator.EditorSettingsalongside the other two.EditorSettings.CodeSplit— three zones need two stored fractions where two needed one.Why a pane rather than a section in the properties
The tuning is read while watching the graph move. It has to be able to be tall while the properties are short, and it must not close itself every time a different node is selected. A collapsing section inside the inspector would fail both.
One flag, not two, for whether the layout runs
This is the one thing here that isn't just plumbing. The editor stops the simulation by not advancing it —
LayoutRunning, which the toolbar checkbox holds — while the panel's own run toggle writes the engine'sPhysicsSettings.Enabled. Wiring those up naively gives two switches for one visible behaviour, and an arrangement where the graph sits frozen for a reason the toolbar doesn't show.So the panel's toggle is shown and written as
LayoutRunning, and the engine'sEnabledstays on: a step the engine is never given cannot run either way.Tests
Three new, covering the wiring rather than the controls — those belong to the library and are covered there:
Panel_OffersEveryGroupOfSettingsPanel_EditsTheGraphsOwnSimulationGraph.Engine.PhysicsSettings— so the pane is wired to this graph's engine, not to a copy of its settingsPanel_RunToggleIsTheSameFlagTheToolbarHoldsLayoutRunningand leaves the engine'sEnabledonEditorWiringTestsalso gained a round-trip assertion for the new split.Verification
dotnet build -c Releaseclean, 0 warnings.Coder.Test332/332 (329 before).Two unused usings were caught locally before pushing — this container now runs the same SDK as CI (10.0.400), so the ktsu analyzers actually load here for the first time rather than being stripped by a workaround.
Not verified visually — this environment is headless. How the panel reads at the pane's default width, and whether the three-way split leaves each pane usable, are the things worth a look when you open it.
🤖 Generated with Claude Code
https://claude.ai/code/session_01D2KNUKr1xJPTEdDmeF2tQN
Generated by Claude Code