Time to clean up 2.0

[dotMorten]

Now that 2.0 experimental has become official, can we start considering that since it's a major version to do some light house-cleaning?

For instance:

• Remove the broken/unusable/replaced Dispatcher properties
• Remove Window.Current that always returns null
• Make Window inherit from DepedencyObject
• In general clean up all these APIs that aren't usable: https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-supported-api

Also see #1660

[DarranRowe]

For the last one in particular, cleaning up the unusable API. Isn't that outside of the scope of this project? Those APIs would be exposed to the developer via the projection, so this means that CsWinRT or CppWinRT should be responsible for this.

CsWinRT uses Microsoft.Windows.SDK.NET.Ref for the projection. CppWinRT grabs the list of .winmd files that it needs to use from the Windows SDK. The .winmd files (which CsWinRT must use to generate the projection) don't really provide any information on what is unusable in a purely desktop environment.

[dotMorten]

@DarranRowe No the unusable APIs are also available to C++ developers. For instance Window.Current or DependencyObject.Dispatcher always returns null, and are common pitfalls when porting code from UWP, because your code compiles but crashes at runtime.

[DarranRowe]

That isn't what I was referring to. Specifically, I was referring to:

In general clean up all these APIs that aren't usable: https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-supported-api

The unusable APIs specified in that link are part of the Windows projection.

Although, it is possible that I misread this and what you really meant to say is that if the UWP only APIs are exposed on any Windows App SDK interfaces, then they should be removed, then I misunderstood and I apologise.

[whiskhub]

I want to add "Unseal all the things" microsoft/microsoft-ui-xaml#780

The reason it hasn't been done before was said to be backwards compatibility.

[Gaoyifei1011]

Now that 2.0 experimental has become official, can we start considering that since it's a major version to do some light house-cleaning?

For instance:

• Remove the broken/unusable/replaced Dispatcher properties
• Remove Window.Current that always returns null
• Make Window inherit from DepedencyObject
• In general clean up all these APIs that aren't usable: https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-supported-api

Also see #1660

我个人认为，与其清理那些遗留的 API（比如 Window.Current, Window.Dispatcher）等等，还不如让 WinUI 3 真正的支持 UWP（因为 WinUI 3 的 UWP 模式是被人为禁用的）

Personally, I think its clear those legacy API (such as Window.Current, Window.Dispatcher), etc., it is better to let WinUI 3 real support UWP (because of WinUI 3 UWP mode is artificially disabled)

[Balkoth]

This would be an invest which generates no return so my guess is -> not gonna happen.

[Marv51]

Maybe the line-endings in TextBox and RichEditBox, could also be re-evaluated in 2.0. There is this old bug that asks for customization. But switching this to \n or \r\n would also be a big improvement. Obviously changing the default line ending would be a significant breaking-change, so 2.0 might be an opportunity.

I find it baffling why just \r (old school Mac line ending) was chosen.

[torum]

A few month ago, I was trying to use Windows.Media.SystemMediaTransportControls for my MPD frontend.
Naturally, I tried to create instance and the intellisense gave me this option:

SystemMediaTransportControls.GetForCurrentView();

However, it gave me a following exception.

System.Runtime.InteropServices.COMException: 'Invalid window handle. (0x80070578)
Consider WindowNative, InitializeWithWindow
See https://aka.ms/cswinrt/interop#windows-sdk'

The error message does not make sense because there is no way to pass a window handle. Now, this may be obvious to someone who have experience in UWP development that GetForCurrentView() is only for UWP(WinUI2), but I hated the idea of UWP and its touch-first so-called "cross-device" UI (turns out I was totally right all along) and did not use UWP at all. So, I had no idea and spent a lot of time figuring out what was going on. Such a waste of time... I've looked for issues in the repo, but all I learned was they are not fixing it : not planned.

If GetForCurrentView() can not be used for WinUI3, why it is there in the first place? Why SystemMediaTransportControls can not be used by WinUI3 app in a straightforward way?

To be frank, this is not a good developer experience at all. Like dotMartine said, It's time to clean up.

[DarranRowe]

Then my suggestion is to open up the Feedback hub and provide feedback there. Anything under the Windows root namespace is bundled as part of Windows. It has nothing to do with the Windows App SDK.

The interop functionality that I mentioned allows the SMTC to be accessed from any desktop application. This means Windows API, WinForms or WPF, so it is completely independent of the Windows App SDK. The application doesn't even have to have the Windows App SDK referenced to use it in the desktop environment.

[torum]

Like you said, CsWinRT is more appropriate I think, but like I said, the are not fixing it.

[DarranRowe]

Changes at the metadata level is a much better option.

To give some examples of this:

There is nothing marking a UWP only API and a desktop only API. So a projection would be required to maintain a curated list of runtime classes and methods supported in UWP mode and desktop mode. What's more, this list is changable, including the fact that GetForCurrentView actually works on two runtime classes in a desktop application.

Then there are other annoyances, like CoreApplication, which seemingly shouldn't be usable in a desktop application, but CoreApplication.Properties is usable in desktop applications. Then there are some methods, such as Package.Current, will work in a desktop application, but only if it has been packaged.

So there are some quirks to the Windows Runtime API that would benefit from at least metadata support.

[torum]

UWP is officially dead. Why would a (new) developer need to learn about already dead tech in detail? Touch-first single window UWP or metro style app were really bad idea. Let's just bury under the ground.
Well, in terms of desktop app development, I've done VB6, Delphi, WPF, FreePascal/Lazarus, and recently AvaloniaUI. And WinUI3/WinAppSDK is the most(if not only) messed up, half broken, developer unfriendly, unenjoyable .... the rest is censored.

[Gaoyifei1011]

Oh, like I said, now I know all that after spending a lot of time (wasted) researching on it. But do I need to know all that? No, I don't think so.

https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-supported-api

[Balkoth]

@DarranRowe While your knowledge is very well appreciated, nothing you added here does help the platform or new developers. While everyone here around since the start of Project Reunion might know these quirks by now, i also think it would be quite reasonable by now (5 years after its inception) to have this sorted out by the team developing WinAppSDK.

Pushing users of the framework to report Windows OS limitations is imho just a bad idea. We have no weight on this and Feedback Hub is not worth any serious time, because most bugs and reports live forever there.

The only ones who can seriously pressure WinDiv into investing any work into this are propably other dev groups inside Microsoft using this framework. And if even they don't care or can't do that we arrive at such problems here.

[DarranRowe]

Understood. I will take this as a statement of I should never post here or on the WinUI repositories ever again.

[Balkoth]

This is not what i said. I explicitly stated that your knowledge is very welcome here.