Proposal: Make `Window` inherit from DependencyObject

[dotMorten]

Proposal: The Window class should inherit from DependencyObject

Summary

One of the most annoying things about the Window class today, and one that diverges a lot from other XAML frameworks is that the Window class is not a DependencyObject, even though we can declare it in xaml.
It limits a lot of typical use-cases.

Rationale

• Window properties does not support binding, as there's no property bag to store it in.
• Window does not support attached properties to extend how it behave right from xaml (like setting backdrop with helper classes, titlebar settings, manage window stage across app sessions etc).
• You cannot find the Window that a UI Element belongs to, because the root XAML element has the Parent as 'null' instead of Window.
• You cannot use resources to set properties on the window (like theme resources applied to titlebar via helper classes in attached properties).

Scope

Capability	Priority
This proposal will allow developers to set Window properties through binding	Must
This proposal will allow developers to extend Window behavior in XAML with attached properties	Must
This proposal will allow developers to reach to theme and resource changes at the Window level	Must
This proposal will allow end users to discover which window a given UI element is part of	Must

Important Notes

• Window today doesn't have a baseclass, so injecting a baseclass (at least from a .NET point of view) is not a breaking change.
  Before: public class Window : ICustomQueryInterface, IWinRTObject, IDynamicInterfaceCastable, IEquatable<Window>
  After: public class Window : DependencyObject, ICustomQueryInterface, IWinRTObject, IDynamicInterfaceCastable, IEquatable<Window>

[mpettit2253]

Isn't this the job of the Content property of the Window (same as in UWP?)

[dotMorten]

Mike Pettit (@mpettit2253) I'm not following? Of the items listed above, none of these are set on the Content.

[mpettit2253]

I'm speaking from a fair lack of experience here, so if I get things really wrong I apologize. I had meant that the Window class in WinUI3 and the AppWindow class in the AppSDK aren't meant to be UIElements or even Visuals like in WPF. They seem to be lightweight bridges to the underlying HWND infrastructure. Choosing to expose them as a name in XAML isn't so helpful, though their recommendation noted below might work.

If I am misreading this and you were able to do these things in Windows 8/UWP, let me know. I am sad about certain things in those stacks that have been left behind like Suspend/Resume. Those features allowed me to write a multi-instance ArcGIS Runtime app that used SceneView and MapView for the main view. Users could open 10 or more instances to work with disparate but related locations, and only the non-minimized ones would take memory, etc. Your resume magic worked great.

That being said, I'll try using the current recommendations in the docs to see if the functionality you list can be done without super pain. It looks like the two big recommendations are:

1. if you need XAML Visual derived features, put a panel or a page as the root and go from there:
   https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/migrate-to-windows-app-sdk/guides/winui3#visual-state-manager-and-pageresources

2. the changing ability to flow into the title bar area may be compatible with their above recommendation:
   https://docs.microsoft.com/en-us/windows/apps/develop/title-bar?tabs=winui3

[MikeHillberg]

I think it would make sense to make Window an element of some kind (such as a ContentControl like in WPF). Actually, an ask that comes up a lot is "why doesn't WinUI just have WPF's Window?".

Part of the answer to that is that in Win8, Xaml's Window was designed to not replicate what's done in UWP by CoreWindow and ApplicationView. For WinAppSDK we similarly want Xaml's Window to complement and integrate the new AppWindow functionality rather than compete with it.

Also in Win8 (UWP) there's only one window per thread, so Xaml Window had no constructor, which meant that you couldn't configure it in Xaml markup; markup is all about calling constructors. But with WinAppSDK we have multiple windows per thread and have in markup now.