Skip to content

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

Closed

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.

Activity

  1. proggeramlug commented on Jul 30, 2026

    @proggeramlug
    ContributorAuthor

    Queue audit (2026-07-30): keeping this open as a valid feature request.

    The original report's “silent 0 handle” description is stale: current main has a Win32 STATIC placeholder in crates/perry-ui-windows/src/widgets/map_view.rs that 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew capability or improvement

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions