-
Notifications
You must be signed in to change notification settings - Fork 724
Description
It's a nasty design error in how SchemeManager works. The crux of it is calling ConfigurationManager.SourcesManager?.Load to causes the _hardCodedConfigPropertyCache to get corrupted for the SchemeManager.Schemes property. Thus any call to get or reset the hard coded defaults returns whatever was just loaded, not the actual hard coded defaults.
In #4287 I implemented a workaround that patches up ThemeManager.ResetToHardCodedDefaults using the dynamic creation of the hard-coded Scheme values. Also Apply to Themes at Initializaton.
This covers up any instance where Scheme has become corrupted.
This does not actually fix the root cause, just work around it.
To reproduce:
- Remove the workarunds in CM with comments like this:
// BUGBUG: ThemeScope is broken and needs to be fixed to not have the hard coded schemes get overwritten.
// BUGBUG: This test demonstrates the problem.
// BUGBUG: See https://github.com/gui-cs/Terminal.Gui/issues/4288- Enable
ThemeScopeTests.UpdateFrom_Corrupts_Schemes_HardCodeDefaultswhich will succeed 100%
Note, I could not figure out how to make this test always fail or succeed with the workarounds; thus it's disabled.
Problem
The fundamental problem is [ConfigProperty] statics need to be value types (or otherwise immutable) Schemes is not; it is a Dictionary that can be modified. Worse, Schemes is referenced directly from ThemeScope.
To fix this properly, the entire design of ThemeManager, wrt Schemes needs to be revisisted.
That is what this Issue is for.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status