dump_ui_spec → edit → build_ui_from_spec looks like a safe round-trip. It is not: the rebuild is a full teardown, and any property the spec schema does not model is reset to class defaults with no diagnostic. Validation reports error_count: 0, warning_count: 0.
Reproduction
On a scratch duplicate of a hand-styled menu widget: dump → rebuild with two deliberate edits → before/after compared with Epic's UMGToolSet.GetWidgetDescription.
Survived: all 15 widgets with identical names and hierarchy, bIsVariable flags, the EventGraph (12 nodes), a member function, both member variables, and the K2Node_ComponentBoundEvent OnClicked bindings — those re-resolve because the recreated widgets carry the same names. Slot layout, anchors, sizeRule/fillWeight, VAlign, border colours and paddings all round-tripped, and both intended edits applied.
Silently lost:
BackgroundBlur.BlurStrength (20 → class default; the blur is simply gone)- Both Buttons' entire
WidgetStyle — custom Normal/Hovered/Pressed tints — so all hover and press feedback reverted to the stock look
- Text localization keys reassigned (namespace →
"", fresh key GUIDs), which breaks existing loc mappings
The signal that exists but is easy to misread
node_counts does report this up front — a rebuild returns created:N, modified:0, removed:N, i.e. always a full teardown, never a differential patch. But that reads as bookkeeping rather than as "everything not in my spec is about to be reset to class defaults", especially when error_count and warning_count are both zero.
Ask, in preference order
- A
mode: "patch" that touches only what the spec names.
- Failing that, make unmodelled-but-present properties a warning, so
warning_count is nonzero when a rebuild is about to drop something.
Why it matters
As it stands the spec path is unusable on any existing hand-styled widget, which is most production UI — it is spec-first for greenfield only. That is a reasonable design, but it is not what the round-trip shape of dump_ui_spec → build_ui_from_spec suggests, and the failure is silent.
dump_ui_spec→ edit →build_ui_from_speclooks like a safe round-trip. It is not: the rebuild is a full teardown, and any property the spec schema does not model is reset to class defaults with no diagnostic. Validation reportserror_count: 0, warning_count: 0.Reproduction
On a scratch duplicate of a hand-styled menu widget: dump → rebuild with two deliberate edits → before/after compared with Epic's
UMGToolSet.GetWidgetDescription.Survived: all 15 widgets with identical names and hierarchy,
bIsVariableflags, the EventGraph (12 nodes), a member function, both member variables, and theK2Node_ComponentBoundEventOnClickedbindings — those re-resolve because the recreated widgets carry the same names. Slot layout, anchors,sizeRule/fillWeight, VAlign, border colours and paddings all round-tripped, and both intended edits applied.Silently lost:
BackgroundBlur.BlurStrength(20 → class default; the blur is simply gone)WidgetStyle— custom Normal/Hovered/Pressed tints — so all hover and press feedback reverted to the stock look"", fresh key GUIDs), which breaks existing loc mappingsThe signal that exists but is easy to misread
node_countsdoes report this up front — a rebuild returnscreated:N, modified:0, removed:N, i.e. always a full teardown, never a differential patch. But that reads as bookkeeping rather than as "everything not in my spec is about to be reset to class defaults", especially whenerror_countandwarning_countare both zero.Ask, in preference order
mode: "patch"that touches only what the spec names.warning_countis nonzero when a rebuild is about to drop something.Why it matters
As it stands the spec path is unusable on any existing hand-styled widget, which is most production UI — it is spec-first for greenfield only. That is a reasonable design, but it is not what the round-trip shape of
dump_ui_spec→build_ui_from_specsuggests, and the failure is silent.