Diese Seite beschreibt ausschließlich tatsächlich implementiertes Verhalten, nicht den ursprünglichen Architektur-Plan. Wo eine im Plan vorgesehene Fähigkeit noch nicht an die Bedienung angebunden ist, steht das hier explizit dabei (siehe z. B. Hierarchie unten zu Drag-&-Drop-Reparenting) — Spekulation über zukünftiges Verhalten gehört nicht in eine Referenzseite.
Modul: Editor/Canvas (editor_canvas), Klassen CanvasRenderer (reine Rendering-/Hit-Test-Logik, ohne ImGui-Abhängigkeit) und CanvasPanel (ImGui-Anbindung).
So funktioniert es:
ImGui::Image() angezeigt — kein direkter Swapchain pro Dokument.SelectionModel-Instanz aus, die auch Hierarchie und Inspector verwenden.ani-Eigenschaft (z. B. ein reiner Text-Container) wird bewusst gar nicht als Box gezeichnet, außer es ist gerade ausgewählt — das entspricht dem bestätigten Verhalten des Originals, das für ein leeres ani überhaupt keine Sprite-Fläche reserviert.MoveControlsCommand + EditTransaction, siehe Undo/Redo & Auswahl).genwnd) selbst ist bewusst kein Zieh-Ziel — ihr Rechteck bestimmt die Größe der Offscreen-Textur und den Ursprung von CanvasViewTransform.rect-Eigenschaft).Modul: Editor/Palette (editor_palette)
Ein eigenes Panel listet jeden bei der ControlTypeRegistry registrierten Control-Typ flach und durchsuchbar auf — dieselbe einzige Quelle der Wahrheit, die auch Parser, Serializer und Inspector befragen (siehe Architektur-Übersicht), nicht eine zweite, unabhängig gepflegte Liste.
Bedienung: Einen Eintrag aus der Palette auf das Canvas ziehen und fallen lassen — an genau dieser Position entsteht ein neues Control dieses Typs, mit automatisch vergebener eindeutiger id (<typ>_1, <typ>_2, …) und einer festen Standardgröße (100×30). Das neue Control wird sofort ausgewählt und zeigt seine Größen-Griffe (siehe oben). Das Hinzufügen landet als ein Undo-Schritt.
Warum jede Property vorbelegt wird: Der Inspector zeigt nur Eingabefelder für Eigenschaften, die als Eintrag im Control bereits vorhanden sind — genau wie im Original kann er keine komplett neue Property-Zeile zu einem Control hinzufügen, das sie vorher nie hatte. Ein frisch abgelegtes Control bekäme dadurch fast keine editierbaren Felder, wenn es nur mit id/rect erzeugt würde. Deshalb füllt die Palette jede Eigenschaft, die der Typ laut Schema kennt (spr, ani, caption, info, frame, pos, …), sofort mit ihrem Standardwert — das neu abgelegte Control ist ab der ersten Sekunde vollständig über den Inspector bearbeitbar.
Jetzt auch enthalten: style, flag und anchor sind seit der Schema-Registrierung dieser drei Eigenschaften (ControlTypeDescriptorFactory::CommonNuiProperties) ganz normale, schema-bekannte Properties wie jede andere — ein frisch abgelegtes Control bekommt also sofort ein leeres, typsicheres Bitflag-Set für alle drei mit, editierbar über dieselben Bitflag-Checkboxen wie bei einem aus einer echten Datei geparsten Control (siehe Inspector unten). Bis vor Kurzem existierten hierfür nur die internen Bitflag-Nachschlagetabellen ohne zugehörige Property — dadurch wurden style =/flag =/anchor =-Zeilen aus echten .nui-Dateien als schema-unbekannt eingestuft und blieben reiner Rohtext, ohne dass z. B. KSTYLE_STRETCH_VERTICAL oder KFLAG_SINGLE_LINE im CanvasRenderer je ausgewertet wurden. Das ist jetzt behoben.
Modul: Editor/Hierarchy (editor_hierarchy)
genwnd) und darunter jedes Kind-Control als flache Liste — passend zur tatsächlich flachen Struktur des .nui-Dokumentmodells selbst (siehe Das .nui-Format), keine künstliche Baumtiefe.id [typ], oder (no id) [typ], falls keine id-Eigenschaft gesetzt ist.SelectionModel, dieselbe Semantik wie im Canvas.Noch nicht angebunden: Drag-&-Drop-Reparenting per Maus in dieser Liste. Der Grund ist strukturell, nicht nur "noch nicht gebaut": NuiDocument bildet exakt die tatsächlich flache .nui-Struktur ab (Wurzel + flache Kind-Liste, siehe oben), es gibt also aktuell keine tiefere Eltern-Kind-Beziehung, in die man ein Control ziehen könnte. Ein ReparentControlCommand würde erst mit einer eigenen, editor-seitigen Hierarchie über dem Dokumentmodell sinnvoll.
Modul: Editor/Inspector (editor_inspector)
Zeigt alle schema-bekannten Eigenschaften des ausgewählten Control-Typs, gruppiert in vier feste Kategorien:
rect)caption, infoflag, anchor und ähnliche Verhaltens-EigenschaftenJede Eigenschaft wird passend zu ihrem PropertyType dargestellt (Textfeld, Zahlenfeld, Bitflag-Checkboxen, …). Eine Änderung wird erst beim Verlassen des Feldes (nicht bei jedem Tastendruck) als ein SetPropertyCommand auf den Undo-Stack gelegt.
Unknown / Advanced: Alle Eigenschaften, die das Schema nicht kennt, verschwinden nicht — sie erscheinen gesammelt am Ende als roh editierbarer Text. Das ist ein bewusster, großer Unterschied zum Original-Editor, dessen hartkodiertes Formular die meisten echten Eigenschaften der meisten Control-Typen gar nicht anzeigen konnte.
Kodierung: Text-Eigenschaften (caption und unbekannte Rohtext-Einträge) werden beim Anzeigen von CP949 nach UTF-8 konvertiert und beim Speichern zurück — siehe Captions & Text-Rendering für den Hintergrund. Ohne diese Konvertierung zeigt ImGui nicht-lateinischen Text als ?-Zeichen an.
Alle drei Panels teilen sich eine SelectionModel-Instanz (siehe Undo/Redo & Auswahl) und einen UndoStack über den gemeinsamen DocumentContext. Keines der drei Panels kennt die internen Details der anderen — die Kopplung läuft ausschließlich über diese beiden gemeinsamen, beobachtbaren Zustände.