Question: Is Window going to be enhanced with necessary properties/methods?

I apologize if others have asked similar questions but searching in the issues on “window” turns up thousands of results since almost every issue mentions the text “window” in it.

The WinUI Window class as it currently stands in Reunion 0.5 is not usable from a developer point of view and is missing the most basic things like being able to set the icon that shows in the title bar, or even the window’s bounds. Even setting the Title property in XAML gives this error:

The XAML Binary Format (XBF) generator reported syntax error ‘0x09C4’ : Property Not Found

And the custom title bar APIs like ExtendsContentIntoTitleBar and SetTitleBar don’t currently seem implemented correctly.

If WinUI is intended to be desktop-oriented, it really needs a solid implementation of a Window class that makes it easy to fully configure the look of the window, its bounds, startup location, custom title bars, etc.

Window should have an easy-to-use API that surfaces at least all the WPF Window-like properties needed for window management.

I found the DesktopWindow repo by @marb2000 that seems to wrap Win32 and provide a lot of the functionality that should be baked into the Window class.

My main question is, will APIs like what is in that other repo be merged into Window? As a consumer of WinUI making an app, we shouldn’t need to learn Win32 APIs to accomplish basic things. Without these basic features on Window, I don’t see how many desktop developers will want to adopt this platform over something like WPF, since it’s an immediate turn-off.

[marb2000]

Hi @billhenn

We are aware of the current implementation of Microsoft.UI.Xaml.Window lacks a lot of basic and expected functionality. This gap is even more significant when you compare it with the WPF/WinForm API set. We are want to add these functionalities to the Window class. However, per our current engineering plan, I don’t believe we can do it by Reunion v1.0. These APIs can be workaround’ed using the Win32 APIs (as you see in my sample code or even in the @dotMorten example ), but others can’t, for instance, everything around multi-window support. Top of my mind is: the WinUI content should respond adequately to display orientations, tooltips mouse clicks don’t work on secondary monitors, release resources properly, XamlRoot inconsistencies, extending testing coverage, and a lot of other blockers. We believe it is better to put our team to work on these blockers instead of adding these basic/expected APIs for the next release.

It will take to time for WinUI to get to the developers the functionalities that WPF gives them. WPF is an excellent UI Platform, and we understand that many developers won’t move to WinUI immediately, and it makes complete sense to us. We have a lot of work to do. We encourage people to continue using WPF and WinForms if these UIs are good enough for them.

About the custom title bar. These APIs have several bugs (some of them very nasty) that are planning to be addressed by 0.8 and 1.0.

I hope this brings a little more clarity to our plans.

[CAKCy]

@Gavin-Williams Thank you so much for your replies! They sure help me climbing the WinUI hill! 😃