Why stuck on WinUI 2?

[Lakshrp112]

I recently came across a statement indicating, "and we're pretty stuck on WinUI 2 indefinitely." I'm curious to understand why Windows Terminal is sticking to WinUI 2 despite being a first-party application. I've thoroughly searched GitHub issues, Microsoft blogs, and more, but haven't found a clear answer yet.

Despite being Microsoft's first-party terminal solution, positioned as a replacement for CMD and PowerShell, Windows Terminal has not migrated to its own solution, even though Microsoft is actively encouraging third-party developers to do so. This discrepancy raises questions about why Windows Terminal, as a flagship Microsoft application, is not taking advantage of newer frameworks like WinUI 3.

Additionally, I'd like to mention that I have no experience or knowledge about native Windows application development. However, I'm interested in understanding why Windows Terminal is sticking to WinUI 2, despite being a first-party application.

The migration to WinUI 3, facilitated by the "Windows App SDK" (formerly known as Project Reunion), would offer a seamless transition without the need for a full app rewrite, as claimed by the Windows App SDK itself. This move could enhance the user experience and enable the adoption of modern features such as proper implementation of Mica.

[zadjii-msft]

There's one key thing that prevents us from using WinUI 3. SwapchainPanels on top of acrylic (and other XAML content). With the way the terminal is currently architected, each pane is a swapchainpanel with a transparent background. This lets us layer the swapchain on top of XAML content. Namely, we use that so the background of a pane can be acrylic, or an image (namely: a gif).

Alas, undocked swapchains can't have transparent backgrounds. So that would mean no acrylic, and no background images. And people love their backgrounds. We've got open dependencies filed to get that sorted out, but it'll probably be a while before those get resolved.

Other than that, the transition isn't that painful. We've even had someone internally prototype the conversion, so we know it can be done. We're also way off the rails in the way we're using a swapchainpanel - we always have been. This isn't something I'd expect other developers to run into in a major way.

[zadjii-msft]

@RokeJulianLockhart What features from WinUI3 would you be looking for in particular? There'd have to be a compelling reason to do the non-trivial engineering work to move to WinUI 3

[RokeJulianLockhart]

#17127 (reply in thread)

@zadjii-msft, ah, nothing in particular. I just have no interest in that feature - it seems strange to withhold such an important architectural improvement for what seems like at best a gimmick.

[zadjii-msft]

People really love acrylic terminals 🤷 I'm not keen to remove a much beloved feature without a plan to replace it. Conversations are ongoing internally with the WinUI & platform folks to come up with a solution here. Something that benefits us will end up benefitting the whole of the platform.

[DHowett]

important architectural improvement

WinUI 3 is only arguably an improvement, and only because WinUI 2 has had bug fixes withheld to make WinUI 3 more compelling.

When it is possible to onboard to WinUI 3 and not take a hit in disk footprint, commit charge and startup time... then it will be an improvement. 🙂

[RokeJulianLockhart]

#17127 (reply in thread)

@DHowett, I estimate that those fixes you refer to were breaking? If so, that makes sense, right? Otherwise, I can't think of what else justifies a new version.