AppWindow.SetIcon(executablePath) was passing the .exe's own path, but that
API requires an actual .ico file path — passing an .exe silently does
nothing, so the window fell back to a generic placeholder icon in the
taskbar and Alt+Tab (the custom title bar icon fixed earlier is a separate,
XAML-drawn Image and was unaffected).
Embed branding/AmiReel.ico as a resource, extract it once to
%LOCALAPPDATA%\AmiReel\app-icon.ico on startup, and call
AppWindow.SetIcon() with that file path instead. Verified via WM_GETICON
against the running window's HWND that both the big and small icons now
resolve to the real AmiReel logo.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The title bar Image used Source="ms-appx:///Assets/Square44x44Logo.scale-200.png".
That resolves fine in a normal build (Assets/ and AmiReel.pri sit next to the exe),
but a single-file self-contained publish (IncludeAllContentForSelfExtract=true)
bundles Content items into the exe in a way ms-appx:// can no longer resolve at
runtime, leaving the title bar icon blank — reproduced with the actual
publish-win-x64.ps1 output, confirmed fixed the same way.
Load the icon from a plain embedded resource instead (same mechanism already
used for ffmpeg.exe/ffprobe.exe): the PNG is embedded via
<EmbeddedResource LogicalName="AmiReel.Assets.TitleBarIcon.png">, and
MainWindow loads it at startup via GetManifestResourceStream + BitmapImage.
SetSourceAsync. This bypasses the ms-appx/MRT resource pipeline entirely, so
it behaves identically in dotnet build, dotnet run, and a single-file publish.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Implements the suggestions from the last review pass:
- Add AmiReel.Tests (MSTest), covering the pure logic in Models/ and
Services/: SupportedVideoFormats, AppSettings normalization,
UserFacingErrors.Summarize, the new FfmpegProgressParser/
FfmpegOutputFilter, RenderPipeline.Validate, BuildProgressMessage, and
MoveSourceVideos. 59 tests, all passing. UI code-behind and anything that
spawns an actual FFmpeg process are left to manual/integration testing.
Exclude AmiReel.Tests\**\*.cs from AmiReel.csproj's default item glob —
it's a subfolder of the app project now, so without the exclude the app
itself was compiling the MSTest-only test files.
- Extract the FFmpeg version/library-banner boilerplate list that
ProcessRunner (live log filter) and UserFacingErrors (error summarizer)
had each duplicated into a shared FfmpegOutputFilter.IsBoilerplateLine;
each caller keeps its own remaining context-specific checks on top.
Also extract ProcessRunner's line-parsing regexes into a standalone
FfmpegProgressParser so it's directly unit-testable without spawning a
process.
- Convert AppSettings and RenderSettings from positional record
constructors to named `required` init properties. Both records had
runs of same-typed consecutive parameters (three string timing fields
in AppSettings; three doubles then five ints in RenderSettings) that a
positional constructor would let get silently transposed at a call site
without the compiler catching it. Update the two call sites
(MainPage.xaml.cs) to object-initializer syntax.
- Add Properties/AssemblyInfo.cs with InternalsVisibleTo("AmiReel.Tests")
and make Validate/BuildProgressMessage/IsNoise internal so tests can
reach them directly instead of only through process-spawning entry
points.
- README: document `dotnet test`, and note that Package.appxmanifest's
Identity is a local-dev placeholder that needs a real publisher/cert
before MSIX distribution.
Verified: dotnet build (solution + test project) is 0 warnings/errors,
dotnet test is 59/59 passing, and the app still launches unchanged.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Remove unused `using Microsoft.Win32;` from MainPage.xaml.cs (leftover
from the WPF OpenFileDialog era; WinUI uses Windows.Storage.Pickers)
- Trim App.xaml.cs down to the two usings it actually needs instead of the
full WinUI3 template boilerplate list
- Change App.MainWindowInstance to an internal setter (only MainWindow
itself should assign it)
- Add AutomationProperties.Name to the icon-only Settings button so screen
readers announce it (it only had a mouse tooltip before)
- Delete Assets/AppIcon.ico: unreferenced by both the manifest and code,
the real app icon comes from ApplicationIcon (branding/AmiReel.ico) and
AppWindow.SetIcon at runtime
- Drop the systemAIModels capability from Package.appxmanifest; the app
doesn't call any Windows AI API, so declaring it is an unnecessary
privilege request
Verified: dotnet build produces 0 warnings/errors, app launches unchanged.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
klevze