공유 위젯을 재사용하며 배운 것
불러오기 패널을 만들면서 이미 있는 세이브 슬롯 위젯을 재사용하기로 했다. 그런데 재사용의 진짜 비용은 위젯을 화면에 그리는 게 아니었다. 그 위젯이 암묵적으로 깔고 있던 계약 세 개를 다 떠안는 것이었다.
숨은 계약 1 — 타입 잠금
공유 슬롯 위젯은 특정 소유 메뉴 타입을 전제하고 있었다. 그 공유 위젯을 고치면 다른 화면이 깨진다. 그래서 위젯을 건드리는 대신 호스트 위젯에서 버튼 이벤트를 직접 바인딩했다. 이름으로 버튼을 찾아 OnClicked.AddDynamic(this, &URetrieveLoadGameWidget::HandleSlot0Clicked) 식으로 붙였다. 공유 에셋은 그대로 두고 호스트가 결선을 흡수한 것이다.
숨은 계약 2 — SlotIndex는 편집할 수 없다
슬롯 번호를 위젯에서 편집할 수 없어서, ScrollBox 자식의 배치 순서(ChildIndex)에서 슬롯 인덱스를 파생시켰다. 대신 ‘0~4 순차 배치가 반드시 지켜져야 한다’는 계약을 코드에 문서로 못 박았다. 순서가 곧 데이터라서다.
숨은 계약 3 — 필요한 위젯이 아예 없다 (그리고 CanvasPanel 함정)
썸네일과 퀘스트 텍스트가 슬롯 위젯에 없어서 WidgetTree->ConstructWidget으로 동적 주입했다. 여기서 함정을 하나 밟았다. VerticalBox·HorizontalBox는 동적으로 만든 자식을 자동 레이아웃하지만,CanvasPanel은 슬롯을 명시적으로 지정해야 한다. 즉 동적 생성은 자동 레이아웃 부모 아래에서만 그냥 ‘된다’. 그걸 모르면 CanvasPanel에 넣은 위젯이 크기 0으로 안 보인다.
배운 점
공유 위젯 재사용의 비용은 렌더링이 아니라 숨은 계약(타입 가정, 편집 제약, 누락 요소)이다. 그 계약을 호스트 C++에서 흡수하면 공유 에셋 무결성을 지키면서 재사용할 수 있다.
동적으로 만든 위젯은 자동 레이아웃 부모(VerticalBox·HorizontalBox) 아래에서만 별도 설정 없이 배치된다. CanvasPanel에 넣을 거면 슬롯을 직접 잡아 줘야 한다.