Skip to content

UI

Purpose

The themed widget set consumers actually call, plus the shared preset-management block the designer is built from. This is SKINT's public drawing surface.

Owns

  • CustomGUIElements — ThemedToggle, ThemedSlider, ThemedTextField, ThemedColorField, ThemedPopup, ThemedEnum, ThemedObjectField and the rest, each taking a label and a ref to the caller's value
  • ThemedProgressBar
  • ThemedPresetBlock — the generic save / load / delete / undo block, including overwrite confirmation and the inline status line

Does NOT Own

  • Style construction or caching — that is Styling
  • Theme persistence — that is the package root
  • Window lifecycle and menu items — that is Editor
  • Path validation — that is SkintPaths

Allowed Dependencies

UI may depend on:

  • UnityEditor GUI APIs and UnityEngine
  • Styling, for the cached styles and geometry
  • Core, for the theme model and file IO

UI should avoid depending on:

  • Editor window types — the block is handed what it needs and returns a result

Notes

Every widget reads like EditorGUILayout with theming applied, which is the whole design intent: a consumer should be able to swap a call and get a themed control without restructuring their window.

Field layout goes through BeginField / EndField, which use EditorGUILayout.PrefixLabel with an explicit style. ThemedLabel(string, string) is deliberately not converted — it is a label, not a field, and giving it a prefix column would misalign it against everything around it.

ThemedPresetBlock is generic over the preset type and honours IPresetSerializable<T> if the type implements it. Deletes move the file to .Trash and offer an undo that survives a domain reload, because the undo target is kept in EditorPrefs rather than in memory. Overwrites ask first, since nothing can bring back an overwritten preset.

File work is deferred out of the layout pass rather than run inline. Raising a dialog from inside a repaint is how you get one per frame.

Failures raise a dialog and log a warning. Successes were historically silent, which is the wrong way round for a destructive action — the one case you most want confirmation of was the one giving none. Save, delete, restore and reset now report into an inline status line, and a second delete warns which preset it has just made un-undoable and where the file still is.

Future Candidates

  • Preset delete undo is single level. The trashed file survives, but only the most recent delete is restorable from the UI.