Start transition from experimental Xaml Islands to packaged WinUI 3 app #59
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Not too much to explain - when we started working on this thing, we wanted to have the shiny Windows 10 (or Windows 11 "followup") GUI and shiny Win10+ features, along with Win32 APIs that provided us with development freedom and access that is so critical and called for in a project such as this.
However, the WinUI 2 GUI has been tightly coupled to the OS and was only consumable on UWP projects (also shipped with Windows 10).
Simply put - in order to use WinUI, you had to use UWP. If you used UWP - you couldn't access Win32 APIs. But you could use UWP for WinUI and for additional Windows 10+ features (like the notifications center) through something called "Xaml Islands".
We decided to experiment with Microsoft's Xaml Islands. The idea was simple - we'd build a WPF app in order to use Win32 and do things like capture output sound, and use Xaml Islands to enjoy the Fluent Design concept introduced in Windows 10 and on. In order to do that, we already needed about 3 projects. One for WPF, one for the "Island" or accessor that hosts the UWP connection, and the UWP project that literally hosted the component.
This created an awkward situation that was painful to manage in terms of bindings and reactivity - whatever is related to access to Win32 APIs had to sit on the WPF project and be called via event handlers (could not be invoked via the UWP part), and things that were common to both execution of effects and GUI would sit in split projects that would be referenced by UWP & WPF.
Additionally, there were bizarre issues that we'd experience due to Xaml Islands being an experimental technology (and instable in that time), that would cause us to upgrade and downgrade every single related NuGet package on a weekly basis. The latest version also had a workaround (related to Xaml Islands being built around Xamarin.Forms) for not being able to build the project - you had to manually copy files from a deep, nested /obj/ folder to an outer /bin/ folder.
Things like this made developer experience horrible. With that, I became busy and was unable to maintain the project. Small features and bugfixes would become 3x harder in terms of time, debugging and investigating. Simple components would not work in very specific cases. Some components had to be rendered programatically in runtime and not via XAML... And so on.
Microsoft started working on Project Reunion - which would set its target to fixing the APIs hell and set a standard set of unified APIs for all Desktop Apps. It would have to include WinUI 3, the successor to the coupled WinUI 2, in a decoupled fashion. It was then renamed from Project Reunion to Windows App SDK (NOT Windows SDK), which was decoupled from the OS, and started shipping with .NET 6.0.
This PR attempts to begin the transition from Xaml Islands to WinUI 3, which is decoupled from the OS and relies on Windows App SDK in order to provide an easier connection between the effects execution and the user interface - allowing for better experiences moving forward, GUI features that communicate directly with Windows APIs, and so on.