Background
v0.5.637 (PR #558) un-stubbed the MapView widget on tvOS, GTK4, Android, and watchOS, rounding out v0.5.636's macOS / iOS / visionOS impls. Windows is the one remaining platform where MapView(w, h) returns a silent 0 handle and the setters are no-ops in crates/perry-ui-windows/src/lib.rs.
Why it's a separate issue
The natural Windows backend is WinUI's Windows.UI.Xaml.Controls.Maps.MapControl — a native, GPU-accelerated map widget. The complication: MapControl lives inside the UWP / WinUI 3 component model, and Perry's Windows runtime is a Win32 app (HWND-based windowing, windows-rs Win32 features). To host a WinUI MapControl inside a Win32 HWND requires:
- XAML Islands integration (
Windows.UI.Xaml.Hosting.WindowsXamlManager + DesktopWindowXamlSource) so WinUI controls can be embedded in a Win32 child window.
- Windows App SDK dependency (and the WinUI 3 stack on top of it) — substantial new footprint for the perry-ui-windows crate.
- Bing Maps API key registration — the user must obtain a key from the Bing Maps Dev Center and pass it via
MapControl.MapServiceToken.
- COM activation context wiring so the WinUI runtime initializes correctly when the Perry binary starts.
This is meaningful work — easily a multi-day effort. It belongs in its own PR rather than getting bundled into a cross-platform un-stub pass.
Alternatives considered (and why not)
- MapLibre Native — the OSS choice on Linux. On Windows it requires Qt or raw Win32+OpenGL embedding; either way it's a 300MB+ build dep with significant link complexity. Not a quick win.
- WebView2 + MapLibre GL JS — would work but the project's stance is no-webview maps; it'd also feel out of place next to the truly native impls on every other platform.
- Direct2D + custom OSM tile renderer — buildable but the rendering quality / interaction polish gap vs MKMapView / Google Maps / libshumate is too large for v1.
Acceptance
MapView(w, h) on Windows returns a real handle backed by a MapControl hosted in an XAML Island parented to the Perry HWND chain.
mapViewSetRegion(lat, lon, latSpan, lonSpan) drives MapControl.Center + zoom-from-span.
mapViewAddPin(lat, lon, title) adds a MapIcon to MapControl.MapElements.
mapViewClearPins() empties MapControl.MapElements.
mapViewSetMapType(0|1|2) sets MapControl.Style to Road / Aerial / AerialWithRoads.
- API key documentation: how the user registers a Bing Maps key and where it gets wired through.
Until this lands, Windows users that import MapView from perry/ui get a silent zero-handle stub that occupies no layout space. That's intentional — it's the same shape every un-stubbed platform ships pre-implementation, so cross-platform code stays linkable.
Background
v0.5.637 (PR #558) un-stubbed the
MapViewwidget on tvOS, GTK4, Android, and watchOS, rounding out v0.5.636's macOS / iOS / visionOS impls. Windows is the one remaining platform whereMapView(w, h)returns a silent0handle and the setters are no-ops incrates/perry-ui-windows/src/lib.rs.Why it's a separate issue
The natural Windows backend is WinUI's
Windows.UI.Xaml.Controls.Maps.MapControl— a native, GPU-accelerated map widget. The complication: MapControl lives inside the UWP / WinUI 3 component model, and Perry's Windows runtime is a Win32 app (HWND-based windowing,windows-rsWin32 features). To host a WinUI MapControl inside a Win32 HWND requires:Windows.UI.Xaml.Hosting.WindowsXamlManager+DesktopWindowXamlSource) so WinUI controls can be embedded in a Win32 child window.MapControl.MapServiceToken.This is meaningful work — easily a multi-day effort. It belongs in its own PR rather than getting bundled into a cross-platform un-stub pass.
Alternatives considered (and why not)
Acceptance
MapView(w, h)on Windows returns a real handle backed by aMapControlhosted in an XAML Island parented to the Perry HWND chain.mapViewSetRegion(lat, lon, latSpan, lonSpan)drivesMapControl.Center+ zoom-from-span.mapViewAddPin(lat, lon, title)adds aMapIcontoMapControl.MapElements.mapViewClearPins()emptiesMapControl.MapElements.mapViewSetMapType(0|1|2)setsMapControl.StyletoRoad/Aerial/AerialWithRoads.Until this lands, Windows users that import
MapViewfromperry/uiget a silent zero-handle stub that occupies no layout space. That's intentional — it's the same shape every un-stubbed platform ships pre-implementation, so cross-platform code stays linkable.