Make AppWindow functionality more discoverable and usable by providing more passthrough APIs on WindowEx

[mikebattista]

Per https://github.com/microsoft/TemplateStudio/issues/4529#issuecomment-1166589303, when comparing WindowEx vs. Window extensions, it appeared that WindowEx on its own was less capable than the extensions. Intellisense and the documentation didn't help me discover that the AppWindow property had many equivalents to what the extensions provide.

If the guidance is to use WindowEx or the extension methods but not both, it would be more discoverable and usable to promote more of AppWindow's functionality on WindowEx itself. You already provide some convenience passthrough APIs like https://github.com/dotMorten/WinUIEx/blob/8cbbce69bd5a9f0ba9dffc48cd09b55ce0c8700b/src/WinUIEx/WindowEx.cs#L255-L262 and https://github.com/dotMorten/WinUIEx/blob/8cbbce69bd5a9f0ba9dffc48cd09b55ce0c8700b/src/WinUIEx/WindowEx.cs#L273-L281.

Have you considered exposing other basics like Show, Hide, Resize, Id, Icon, etc. directly on WindowEx as well to improve discoverability and usability? I would expect these would be simple passthroughs as you've done already with the above APIs.

[dotMorten]

I think this is a fair argument - a bit caused by the evolution of WinUIEx over time as well as WinUI 3. WinUI have since added several members to AppWindow that WinUIEx already had, so they are now effectively passthrough - they weren't always.

Generally with methods I was relying on Extension methods, but for a lot of stuff I wanted to set things in XAML so exposed the properties for easier configuration of your window.

I'm not 100% sure how we could address this, without introducing a major set of breaking changes - something I'd be quite reluctant to do.

If the guidance is to use WindowEx or the extension methods but not both

I might have been a bit hasty on that recommendation. Extension methods add methods to WindowEx, but WindowEx itself is adding properties for configuration. I think this is a good split.

Where it gets tricky/ugly is when the extension methods also does similar functionality as the properties, but since we don't have extension properties in C#, these are mapped as methods, and you'll often get a Get/Set[propertyname]() method in addition to the WindowEx property. As long as they do the same thing though, I'm not sure it's such a big problem?

[mikebattista]

I might have been a bit hasty on that recommendation. Extension methods add methods to WindowEx, but WindowEx itself is adding properties for configuration. I think this is a good split. Where it gets tricky/ugly is when the extension methods also does similar functionality as the properties, but since we don't have extension properties in C#, these are mapped as methods, and you'll often get a Get/Set[propertyname]() method in addition to the WindowEx property. As long as they do the same thing though, I'm not sure it's such a big problem?

The duplication is what originally led us down the path of using WindowEx without the extensions, but if the recommendation is to use them together, then passing through to AppWindow is less necessary, since the extensions will be directly available on WindowEx, at the expense of perceived duplication. If we have to choose between living with the duplication but getting all the functionality vs. exposing a bunch of passthrough APIs and potentially introducing major breaking changes, then I'd be ok living with the duplication.

[dotMorten]

@mikebattista I think v2.0 could have some cleanup of duplication - I'd like to have a chance to deprecate for a few releases first though, and I'd prefer to just keep it small.