[Feature]: XAML Designer

1. Summary

An interactive visual XAML designer in VS Code: a design surface where you drag controls from a toolbox, select and move/resize elements with handles, and edit properties in a property grid — with all changes written back to the XAML text (two-way, text-authoritative). It builds on the XAML Visualizer, adding hit-testing, selection, manipulation, a toolbox, and a property/events panel. This is the most ambitious C-item and the closest thing to Visual Studio's XAML designer.

2. Problem / motivation

VS Code and Visual Studio has no interactive WinUI designer. A XAML desginer has been a highly upvoted request on the WinUI repo for several years now. Developers want the option to view and edit their WinUI applications live in a designer similar to the experience offered with WPF.

3. Similar Solutions

Tool	Approach
Visual Studio XAML Designer / Blend	Full design surface, drag/drop, property grid, states/animations; WPF/UWP strong, WinUI 3 limited.
Uno Hot Design	Runtime designer: manipulate the running app; changes hot-reloaded to source.
Avalonia	Strong previewer; interactive design is limited.
Web designers (Webflow, Figma-to-code)	Direct-manipulation → code.

Takeaway: interactive WinUI design is genuinely hard and under-served.

4. Goals / non-goals

Goals

• Toolbox of common WinUI controls; drag-drop onto the surface inserts well-formed XAML at the right node.
• Selection via click; multi-select; move/resize with handles; alignment guides + snapping; grid/margin editing.
• Property grid (typed editors: enums as dropdowns, brushes as color pickers, thickness/size editors, resource pickers) and an Events section that creates/navigates to handler stubs in code-behind.
• Text-authoritative round-trip: every design edit is a minimal, formatting-preserving XAML text edit; hand-edits in the XAML reflect back in the designer. No proprietary designer metadata in the file.
• Undo/redo integrated with VS Code's text undo stack.
• Layout container awareness (Grid rows/cols, StackPanel order, Canvas coordinates).
• Works in VS Code / Cursor / Windsurf.

Non-goals (v1)

• Visual states / storyboard / animation authoring (Blend-level) — future.
• Style/template/ControlTemplate visual editing — edit as text for now.
• Data-binding designer wizardry beyond a basic {x:Bind}/{Binding} helper.
• Designing against a running app (runtime mode) — future, shared with C5.

5. Proposed implementation

VS Code Webview (design surface)
   toolbox │ canvas(select/drag/resize) │ property+events grid
        ▲            │ manipulation intents (move X to (r,c), set prop, insert control)
   render frames     ▼
   + hit-test   C4 interaction controller (extension)
   metadata          │  ├─ maps intents → minimal XAML text edits (formatting-preserving)
        ▲            │  ├─ maps text edits → re-render + reselect (round-trip)
        └── B4b design-time engine (render + hit-test + layout metadata) ── uses C1 type system

• B4b engine provides: render frames (as C3), hit-testing (point → element), element bounds & layout metadata, and property metadata (types, defaults, categories). C4 consumes these; it does not render or lay out itself.
• Interaction controller turns gestures into XAML text mutations using an AST/CST that preserves whitespace/comments/attribute order (reuse the manifest editor's format-preserving edit approach and/or C1's parser). This keeps the file authoritative and diff-clean.
• Property grid is generated from B4b/C1 property metadata; value editors chosen by type.
• Events create handler stubs in the paired .xaml.cs (Roslyn) and wire the attribute.
• Selection sync: editor caret ↔ selected element ↔ property grid stay in sync.

6. API / contribution surface

"contributes": {
  "customEditors": [{
    "viewType": "winapp.xamlDesigner",
    "displayName": "WinApp XAML Designer",
    "selector": [{ "filenamePattern": "**/*.xaml" }],
    "priority": "option"        // opt-in; text editor remains default
  }],
  "commands": [
    { "command": "winapp.xaml.openDesigner", "title": "WinApp: Open in XAML Designer", "category": "WinApp" },
    { "command": "winapp.xaml.toggleDesignerSplit", "title": "WinApp: Toggle Designer/XAML Split", "category": "WinApp" }
  ],
  "configuration": {
    "winapp.designer.snapToGuides": { "type": "boolean", "default": true },
    "winapp.designer.showGrid": { "type": "boolean", "default": true },
    "winapp.designer.defaultInsertContainer": { "enum": ["auto","grid","stackpanel"], "default": "auto" }
  }
}

Interaction protocol (surface ↔ controller), illustrative:

{ "op":"select", "elementId":"btnIncrement" }
{ "op":"move", "elementId":"DarkToggle", "toGridCell":{ "row":3, "col":0 }, "margin":"0,20,0,0" }
{ "op":"setProperty", "elementId":"DarkToggle", "name":"IsOn", "value":"True" }
{ "op":"insert", "control":"ToggleSwitch", "parentId":"rootStack", "index":2 }
{ "op":"addEventHandler", "elementId":"DarkToggle", "event":"Toggled" }  // → stub in .xaml.cs

7. Design tradeoffs & alternatives

• Text-authoritative vs designer-authoritative. Text-authoritative avoids lock-in and keeps diffs clean but makes some manipulations (e.g. re-parenting inside complex templates) harder to express as minimal edits. Strongly recommend text-authoritative — it's what serious XAML developers expect.
• Design-time vs runtime designer. Design-time = no build/run, but lower fidelity for code-driven UI; runtime (Uno-style) = high fidelity but heavier and couples to C5. Start design-time.

8. Dependencies & risks

• Hard dependency on B4b for render + hit-test + layout/property metadata; C4 is gated by it.
• Round-trip correctness is the top engineering risk — minimal, faithful text edits across arbitrary hand-authored XAML is subtle; needs a strong CST and extensive tests.
• Fidelity expectations: users will compare to VS; manage scope + messaging.
• Effort: this is a multi-quarter effort even with B4b; consider staging behind C3 + C1 maturity.

9. Open questions

1. Does B4b expose hit-testing, layout rects, and re-parenting affordances — and on what timeline?
2. How much layout-container intelligence in v1 (Grid definitions editor? auto-Grid.Row assignment?)?
3. Is a future runtime design mode (shared with C5/C6) in scope for the roadmap, and does that change v1 architecture?