Summary
Add a .NET MAUI provider (README ""Future work"").
Background
MAUI on Windows renders through WinUI 3, so WinUI3Provider already captures the visual tree. A MauiProvider should overlay MAUI-level semantics on top (not replace WinUI3 walking).
Scope
- Detection:
Microsoft.Maui.dll loaded in the target.
- Map WinUI elements back to MAUI virtual-view types and
x:Name where possible.
- Document the relationship to
WinUI3Provider (enrichment overlay).
Acceptance criteria
lvt --name <mauiapp> annotates elements with MAUI types/names in addition to WinUI3 info.
Testing requirement: New framework providers/plugins must ship with a minimal sample app built with that UI framework (so the provider can be exercised end-to-end), plus automated tests. Follow the existing pattern (integration tests launch a real target app).
Filed as part of turning README/docs "Future work" into tracked issues. See docs/architecture.md and CONTRIBUTING.md (""Adding a new provider"") for conventions.
Summary
Add a .NET MAUI provider (README ""Future work"").
Background
MAUI on Windows renders through WinUI 3, so
WinUI3Provideralready captures the visual tree. AMauiProvidershould overlay MAUI-level semantics on top (not replace WinUI3 walking).Scope
Microsoft.Maui.dllloaded in the target.x:Namewhere possible.WinUI3Provider(enrichment overlay).Acceptance criteria
lvt --name <mauiapp>annotates elements with MAUI types/names in addition to WinUI3 info.Testing requirement: New framework providers/plugins must ship with a minimal sample app built with that UI framework (so the provider can be exercised end-to-end), plus automated tests. Follow the existing pattern (integration tests launch a real target app).
Filed as part of turning README/docs "Future work" into tracked issues. See
docs/architecture.mdandCONTRIBUTING.md(""Adding a new provider"") for conventions.