klevze
603af17e56
The repo carried two parallel UIs (WPF + WinUI) sharing Models/Services via
cross-directory Link includes. Now that WinUI is the only frontend, collapse
the structure so the WinUI project IS the repo root instead of a nested
sibling folder:
- Delete the WPF project entirely (App.xaml, MainWindow.xaml, csproj) and its
bin/obj output
- Move AmiReel.WinUI/* up to the repo root (App, MainWindow, MainPage,
DialogHelper, Assets, Package.appxmanifest, app.manifest, Properties,
.github/instructions, AGENTS.md) via git mv, preserving history
- Rename AmiReel.WinUI.csproj -> AmiReel.csproj; regenerate the solution as
AmiReel.slnx (the newer XML solution format) with a single project
- Rename namespace AmigaDB.VideoRenderer.{Models,Services} -> AmiReel.{...}
and AmiReel_WinUI -> AmiReel across all files, including the embedded
ffmpeg/ffprobe resource logical names in the csproj and ToolExtractor
- Models/ and Services/ no longer need the Link-based cross-directory
<Compile Include>; they're picked up by the SDK's default globbing now
that they live under the project directory
- Rename assets/ -> branding/ (source icon art) to avoid a case-insensitive
collision with Assets/ (packaged tile art) once both sit at repo root
- Merge the two .gitignore files into one; track the PublishProfiles pubxml
files instead of ignoring them (no secrets, and they keep publish
reproducible across machines) as branding, gitignore, etc.
- Simplify publish-win-x64.ps1 (drop the -Target Wpf/WinUI switch, there's
only one target now) and rewrite README.md to describe the single-project
layout, build/run/publish commands, and file structure
Verified: dotnet build succeeds for both AmiReel.csproj and AmiReel.slnx, and
the built exe launches and renders identically to before the move.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
6.0 KiB
6.0 KiB
description, applyTo
| description | applyTo |
|---|---|
| WinAppSDK & Windows Platform SDK -- API namespace catalog and lookup guidance | **/*.cs, **/*.xaml, **/*.csproj |
Windows APIs -- WinAppSDK & Windows Platform SDK
Sample-First Rule
Agent Rule -- MANDATORY: Before implementing any WinAppSDK or Windows Platform SDK API you have not used before, you must search the sample repositories below for a working example first. Do not guess API usage patterns from documentation alone -- the docs often omit critical details that only the sample code reveals. Search all of the following repos, not just one:
| # | Repository | What it covers |
|---|---|---|
| 1 | WindowsAppSDK-Samples | All WinAppSDK features (AI, windowing, lifecycle, notifications, etc.) |
| 2 | AI Dev Gallery | On-device AI/ML patterns, model usage examples |
| 3 | WinUI-Gallery | UI control patterns and XAML examples |
How to apply
- Find the right API -- Translate the user's scenario/requirement into common API/programming keywords, then search the API references (Part A-B below) using those keywords to identify which API fits.
- Search for samples -- Once you know which API to use, search each sample repo above for the class name to find a working example.
- Study the sample -- Read the sample's Model / ViewModel / Service layer to understand how the API is actually called -- object lifetime, required parameters, data preparation, error handling.
- Adapt the sample pattern into our MVVM architecture -- don't copy the sample structure wholesale, but match its API call sequence exactly.
Agent Rule: Before implementing any feature that involves a platform capability, consult this file to check whether a built-in API already exists. Always verify exact class names, method signatures, and availability by following the reference links -- do not guess API shapes.
Part A -- Windows App SDK APIs
Full API reference: https://learn.microsoft.com/en-us/windows/windows-app-sdk/api/winrt/
Agent Rule: Do not rely on a hardcoded namespace list -- the SDK is updated frequently. Instead, search the API reference above by converting the user's scenario into common programming keywords.
How to search
- Translate the user's request into API/programming terms. Examples:
- "I want to describe an image" -> search for:
image description,ImageDescription,describe image - "Add a notification" -> search for:
notification,toast,AppNotification - "Pick a file" -> search for:
file picker,StoragePicker,FileOpenPicker - "Make the window always on top" -> search for:
AppWindow,presenter,compact overlay
- "I want to describe an image" -> search for:
- Search the WinAppSDK API reference using
web_searchorweb_fetchwith those keywords. - Verify the class/method exists in the SDK version used by this project (check
.csproj<PackageReference>forMicrosoft.WindowsAppSDKversion).
Key reference links
| # | Link | When to consult |
|---|---|---|
| 1 | WinAppSDK API Reference (full) | Always -- search and look up exact class/method signatures here |
| 2 | Windows App SDK overview | Feature overview, architecture |
| 3 | Release notes (stable) | API availability, version support, breaking changes |
| 4 | Windows AI overview | All AI options: Windows AI APIs, Windows ML, Foundry Local |
| 5 | Get started with Windows AI APIs | Prerequisites, project setup, first AI call |
| 6 | Windows ML overview | Custom ONNX model inference |
| 7 | Foundry Local | Run OSS LLMs locally |
Part B -- Windows Platform SDK (UWP / WinRT APIs)
Full API reference: https://learn.microsoft.com/en-us/uwp/api/
Agent Rule: The Platform SDK (
Windows.*namespaces) is very large and constantly evolving. Do not rely on a hardcoded list. Search the API reference by translating the user's requirement into programming keywords.
How to search
- Translate the user's request into API/programming terms. Examples:
- "Send a Bluetooth message" -> search for:
Bluetooth,RFCOMM,BluetoothDevice - "Get the user's location" -> search for:
geolocation,Geolocator,position - "Read text from an image" -> search for:
OCR,text recognition,OcrEngine - "Copy to clipboard" -> search for:
clipboard,DataTransfer,DataPackage
- "Send a Bluetooth message" -> search for:
- Search the Platform SDK API reference using
web_searchorweb_fetchwith those keywords. - Check for WinAppSDK equivalent -- some Platform SDK APIs have newer equivalents in Part A. Always prefer the WinAppSDK version when both exist.
Key reference links
| # | Link | When to consult |
|---|---|---|
| 1 | Platform SDK API Reference (full) | Search here for any Windows capability not in WinAppSDK |
| 2 | Windows SDK downloads | SDK versions and downloads |
Validation
- Before implementing any platform feature, confirm the API is available in the current Windows App SDK version by checking the release notes.
- For features requiring specific hardware (NPU), provide a graceful fallback for unsupported devices.
- When both WinAppSDK and Platform SDK offer a similar API, prefer the WinAppSDK version.