Default Standards palette on when setting is absent (#3408)#3536
Merged
Conversation
Make GeneralSettingsFile.UseStandardsPalette nullable (bool?): null means the user has never chosen and resolves to on via the new EffectiveUseStandardsPalette; an explicit true/false (written by the View-menu toggle) is honored, so a user who opted out stays out. The tree-view read sites and the menu checkbox now read EffectiveUseStandardsPalette. The menu toggle still writes a concrete true/false, so the palette can still be turned off from View > Standards palette. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Closes #3408.
What
Flip the default so the Standards palette is on for users who have never made an explicit choice, while keeping the View-menu toggle able to turn it off.
Implements the issue's recommended Option 1 (nullable backing field):
GeneralSettingsFile.UseStandardsPaletteis nowbool?.null= never chosen; a non-null value = the user's explicit choice.EffectiveUseStandardsPalette => UseStandardsPalette ?? truecentralizes the "absent → on" resolution. The constructor no longer forcesfalse, so a fresh settings object (and any file lacking the element) resolves to on.ApplyStandardsPaletteMode,CreateRootTreeNodesIfNecessary, the refresh-chips path) and the View-menu checkbox now readEffectiveUseStandardsPalette. Object-null (settings not yet loaded) still falls back to the classic tree, unchanged.true/false, so View → Standards palette can turn it off, and an opt-out survives the default flip.Known limitation (by design, per the issue)
UseStandardsPaletteshipped as a non-nullableboolin #3404, so every user who launched a palette-capable build and saved settings already has<UseStandardsPalette>false</UseStandardsPalette>auto-written. Those users are indistinguishable from an explicit opt-out and will not flip to on — only users whose file lacks the element (fresh installs / never-saved) get the new default. This is the "explicitly opted out stays out" trade-off the issue chose Option 1 for. Flipping the auto-falsecohort too would require the heavier Option 2 (one-time migration).Tests
GeneralSettingsFileTests(new): resolution of null/false/true → effective value, the constructor default (null → on), and an XML round-trip proving an absent element resolves to on while a written value is honored. Red-first verified by inverting?? true→?? false(3 cases went red). FullGumFull.slnbuilds clean; menu/tree-view/composition suites green (35/35).