Core¶
Purpose¶
The theme as data, and the two things every other territory needs in order to read or write it: a resolver that answers "what colour is this, now", and file IO that reports failure instead of throwing or logging.
Owns¶
SkintThemeSettings— the serialised theme: 36 colours, 4 font sizes, 4 spacing tokens, 1 animation speedThemeColorResolver— reads one value out of the active themeSkintIO— read, write, move and delete, each returning success and an error string
Does NOT Own¶
- Where the theme is stored, or when it is written — that is
ThemePersistenceServiceat the package root GUIStyleconstruction of any kind- Any editor window or widget
- Preset file naming and path validation — that is
SkintPaths
Allowed Dependencies¶
Core may depend on:
UnityEngineforColorandJsonUtilitySystem.IO
Core should avoid depending on:
- Styling, UI or Editor territories — the dependency runs the other way
UnityEditorGUI APIs
Notes¶
Every field on SkintThemeSettings carries an initialiser, and that is load-bearing rather than tidiness. JsonUtility constructs the object before overwriting the fields a preset actually contains, so a preset written by an older version keeps sensible values for anything added since instead of reading as zero. The spacing tokens added in P4 rely on this entirely, and GeometryTests pins it rather than assuming it.
SkintIO never logs. It returns (bool, out string error) so the caller decides whether a failure is a dialog, a status line or silence — a decision the UI territory is in a position to make and the IO layer is not.
ThemeColorResolver used to take dark and light fallback colours alongside the selector, returning those unless a theme mode was active. The mode only ever had one value, so the fallbacks were unreachable: about a hundred colour literals maintained in parallel with the theme and never drawn. They are gone.
Future Candidates¶
SkintThemeSettingsis a flat 45 fields. If it grows much further, grouping colours by territory would make the designer easier to lay out.