Skip to content

MapView on Windows: WinUI MapControl backend (follow-up to #517) #559

@proggeramlug

Description

@proggeramlug

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:

  1. XAML Islands integration (Windows.UI.Xaml.Hosting.WindowsXamlManager + DesktopWindowXamlSource) so WinUI controls can be embedded in a Win32 child window.
  2. Windows App SDK dependency (and the WinUI 3 stack on top of it) — substantial new footprint for the perry-ui-windows crate.
  3. Bing Maps API key registration — the user must obtain a key from the Bing Maps Dev Center and pass it via MapControl.MapServiceToken.
  4. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions