Repository navigation
MapView on Windows: WinUI MapControl backend (follow-up to #517) #559
Description
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 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.- 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.
Activity
fix(ui-windows): Windows UI parity sweep (v0.5.778)
proggeramlug commentedon Jul 30, 2026
Queue audit (2026-07-30): keeping this open as a valid feature request.
The original report's “silent
0handle” description is stale: currentmainhas a Win32STATICplaceholder incrates/perry-ui-windows/src/widgets/map_view.rsthat returns a real widget handle, occupies the requested layout space, retains region/pin/map-type state, and visibly updates its label. The public widget docs also identify Windows as a stub.The acceptance criteria are still unmet, however: there is no WinUI/XAML Islands
MapControl, Windows App SDK integration, map service token plumbing, or native map rendering. That remains the substantial feature tracked here, so this should not be closed as already fixed.