☎👩‍💻 August WinUI Community Call (August 19, 2020)

[anawishnoff]

The call has now finished, and you can watch the recording here: https://youtu.be/0SZWXDJaKYs!

Try out the WinUI 2.5 pre-release package and let us know what you think: https://aka.ms/winui2-prerelease

---

Details

Date: Wednesday August 19, 2020
Time: 16:00-17:00 UTC (9:00-10:00am Pacific)

Anyone and everyone is welcome - no pre-registration is required.
This will be an informal interactive live stream directly with members of our engineering team.

Format

In this community call we'll be welcoming two guests from the WinUI team at Microsoft.

At the end of every community call we have a Q&A session where our team and guests answer your questions about all things WinUI.
Ask your questions in the comments of this issue! If any questions come up during the call, you can ask them live in the comments as well.

Agenda

Intro, updates on WinUI
Updates on WinUI 2.5, new features
Roadmap updates for WinUI 3
Updates on open-sourcing WinUI 3 with @adambarlow
Aligning design systems with design tokens with @kikisaints
Q&A

[AnFunctionArray]

OK my question is - would it be possible to expose ICoreWebView2 in from Microsoft::UI::Xaml::Controls::IWebView2 so we can do things like send web requests in WinUI3.

Btw I was able to acquire said interface anyway (some undocumented magic) however now I have a more general questions - when is the next WebView2 Community Call to ask when will local file hosting be available and when binary web messages will be supported.

It seems for me the current development of WebView2 is kinda second priority and heavily neglected (for example I can give this comment to the feature request for binary web messages (it basically gives us a cloudy promise to be looked into after a month on Jan 10 but here we are August and still no progress seems to be made).

Those are pivotal feature for my XAML application using WinUI3. I plan to make a game using C++/C as backend and WebGPU/JavaScript as frontend. I would need a binary interface between my app and locally hosted web application to transfer geometry data and compiled shaders.

[nerocui]

Are there progress/decisions made in terms of rust support?

Are there partners (internal or external) that are working with WinUI Team to use WinUI 3 in their apps?

[shaheedmalik]

Any progress on fixing background acrylic? #2236

[Parth]

A +1 on the ask for rust support. Just to make it clear the small effort thing that would have a large impact is simply: "a hello world for xaml + rust" (as stated here).

@kennykerr said it's on his list, I think this is more eagerly sought after than the team realizes.

[adambarlow]

@bsld thank you for your feedback. We are planning on having core webview access by our November preview for WinUI. We are also prioritizing local file access, so we certainly haven't forgotten about this. In terms of the binary web messages I'll have to defer to @liminzhu. Perhaps you could ping him for an update on that public issue that you have posted.

[cirrusone]

Any chance of some progress updates on these issues? Bugs to be fixed in WinUI 3 Preview 2

[riverar]

[cut/paste]

Q: Where is the WinUI 3 dev status document shown during the February WinUI Community Call? Developers still have no idea what's truly landing in WinUI 3 and we're inching closer to preview go-live.

[liminzhu]

@bsld thanks for reminding us of the arraybuffer issue. Is this something you need, or an example you pick? I'm more than willing to discuss your scenario and see if this needs to be re-prioritized.

I can say that the WebView2 project is ongoing and a high priority to us. We are at the moment working on some of the more pressing issues for GA. As you can see there are ~400 GitHub issues on our feedback repo and we also have a lot of other asks from internal or private conversations. We triage asks as they pop up, but inevitably a good number of them are towards the tail end of backlog and have to be investigated over the years.

[AnFunctionArray]

@liminzhu Thanks for replying. Well yes as I've mentioned I would need this features if I want to implement sending back and forth vertex and index data for my render. I would like to use the Windows back-end to parse 3mf files and send them as array-buffers to the WebView2 as requested. Then possibly I would like to send back some data to be processed by the faster native hosting app.

Maybe just maybe if you were to implement proper local file access - I could host the output (and input) as files and then use them to communicate instead of directly sending messages but at this point why not implement messages as well.

[niels9001]

What updates are there, related to:

• Customizing the window: the ability to create borderless (and transparent) windows (Proposal: Borderless transparent window background support in apps using WinUI #1247)
• Acrylic support in 3.0 or 3.1 (Why must background acrylic be discontinued in WinUI 3? That will surely devastate and disappoint many, for obvious reasons #2236)

[liminzhu]

@bsld thanks for the details! I will make sure this additional input gets factored in when we're looking at our backlog. Right now, it would still be behind some other items.

Local fs access is definitely way, way up in terms of priority, as this is critical path for a lot of apps. You will likely see support for this sooner than the arraybuffer one. I believe we're aiming to have local fs access in the Nov release. This is engineering plan rather than a customer promise though, as there are things that can affect timelines.

[jtbrower]

Debugging Difficulties and Guidance

I have now been developing in WinUI for about a month or so. I started out by writing libraries that could fill in for the missing Window features, compared to those available in WPF. Once I had a decent start on those I began porting one part of my rather large WPF application. Although I really enjoy learning new frameworks and solving technical problems, I am beginning to feel burdened by the amount of effort involved in a WPF to WinUI port. I believe that this is mainly due to the lack of more specific exception messages from the framework. I know I have problems with my own XAML as I ported it from WPF, but lord is it difficult to determine what the cause of the exceptions that I hit are.

Example of Error Messages for a simple XAML Error

Take for example the mistake that I made when defining a XAML StaticResource for the type "Double". I thought that I could add a using for System and then define the resource with sys:Double. As you can see from the exception message below, it would be extremely difficult to know what type of XAML parsing error had occurred. When issues like this occur, I have to start backing out each and every block of XAML until the code runs without exception. Since it takes much longer to launch a packaged application, its a very tedious, time consuming and error prone process.

Writing raw XAML is error prone, but when porting hundreds of XAML files from WPF, errors are unavoidable. My mistake was using sys:Double instead of x:Double.

xmlns:sys="using:System"
...
sys:Double x:Key="DoubleKey">.5</sys:Double>

Microsoft.UI.Xaml.dll!7A6F17CF: (caller: 7A471CB9) Exception(1) tid(85cc) 80004005 Unspecified error
Exception thrown at 0x76119862 in Oceanside.VirtualKeyboard.Sample.App.exe: Microsoft C++ exception: wil::ResultException at memory location 0x00D79C40.
Exception thrown at 0x76119862 in Oceanside.VirtualKeyboard.Sample.App.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.
Microsoft.UI.Xaml.dll!7A6F2F43: (caller: 7A4CE21A) ReturnHr(1) tid(85cc) 80004005 Unspecified error
    Msg:[Microsoft.UI.Xaml.dll!7A6F17CF: (caller: 7A471CB9) Exception(1) tid(85cc) 80004005 Unspecified error
] 
Exception thrown: 'Microsoft.UI.Xaml.Markup.XamlParseException' in winrt.runtime.dll
WinRT information: Could not create a new view because the main window has not yet been created
An exception of type 'Microsoft.UI.Xaml.Markup.XamlParseException' occurred in winrt.runtime.dll but was not handled in user code
WinRT information: Could not create a new view because the main window has not yet been created
XAML parsing failed.

Out of Memory Compile Error

I am also slowed down by Visual Studio running out of memory for what is now only a 9 project solution. When it happens, a subsequent recompile is successful. I have not reported this because I have a rather jaded opinion regarding Visual Studio and the effort required to report an issue with them. I am assuming that this is not a WinUI problem because some of the bugs I have reported to the VS team this year were caused by VS running out of memory. My point isn't to report this issue here, but anytime you need to recompile with Visual Studio, it leads to a loss in development time. I need to find a better way to debug WinUI applications and hope that your team has recommendations for all of us that might smooth the transition to WinUI. The example I gave above is one of many obscure messages that has done little to help me find the cause. Considering I have hundreds of XAML files to port, this could be time prohibitive to any company that has deadlines. Fortunately, I do not have any deadlines at this time, my main goal is a quality re-write with the latest Microsoft technologies.

By the way, I do appreciate the fact that the WinUI targets file explicitly mentioned the out of memory error, kudos to the author.

4>D:\OSPOS5\VirtualKeyboard\artifacts\globals\microsoft.winui\3.0.0-preview2.200713.0\build\Microsoft.UI.Xaml.Markup.Compiler.interop.targets(561,9): Xaml Internal Error error WMC9999: Not enough memory resources are available to process this command. (Exception from HRESULT: 0x80070008)
4>Done building project "Oceanside.VirtualKeyboard.Sample.App.csproj" -- FAILED.
========== Build: 3 succeeded, 1 failed, 5 up-to-date, 0 skipped ==========
========== Deploy: 0 succeeded, 0 failed, 0 skipped ==========

TLDR

I think that everyone would benefit from a list of tips and tricks to help us catch these errors without using process of elimination and recompile.

[dotMorten]

During the Uno conf, @ryandemopoulos presented a roadmap that yet again changed, now skipping a much needed September preview. Why the constant changes to the roadmap?

[jtbrower]

@dotMorten thank you for sharing that information. The sooner I know these things the quicker I will be able to decide if I can continue to hang in there or potentially focus my attention on other parts of my effort. I think the sure size of their effort must be overwhelming, but I also worry that Microsoft will suddenly switch focus making my plans for Desktop WinUI irrelevant. Speaking of Uno I went and took a look at it again a couple of days ago due to the battles I have been having trying to port from WPF. I thought that maybe I could gain an insight to see how the Uno team was using WinUI. I was really impressed with the amount of progress they have made and the details they provided in their latest release.

I was really looking forward to September's release, but seeing the agenda for this coming meeting I wondered if something had changed. All I want is the ability to port a WPF Desktop application over to the more modern and performant UWP flavor XAML without the UWP sandbox and the ability to use multiple Windows. I have waited patiently since 2012 and truly hope the plans to provide this through WinUI 3 have not changed.

[aerojam]

First, thank you for this great UI library, its potential is huge. My question is: Are there any plans for more specific UX Guide for using WinUI? Or will be some 1st class Windows applications (Mail, Photos, File Explorer, Office) that would inspire, how to use WinUI and Fluent Design together to make great Windows apps for touch, mouse and ink? Thank you!

[jtbrower]

After learning from @dotMorten that there was an updated schedule presented at the Uno conference on August 12th, I decided to dig through the 4.5 hour long video to this location where @ryandemopoulos shared that the September preview has been cancelled. The github roadmap here needs to be updated.

I truly do appreciate the hard work that all developers put in, and I don't mean to make the release of WinUI seem simple. That stated, it would have been a good idea to share that schedule where it belongs, in the WinUI repo, instead of casually waiting until August 19th to break the news to everyone who has been trying hard to make WinUI work. I appreciate you all, but its hard enough to plan around a missing production release date than to have previews yanked and learn about it through the Uno team. An outside viewer might say, "but its all in preview and you shouldn't plan around that". The problem is, that desktop application developers around the globe have wanted to migrate to UWP flavor XAML since it came out in 2012, but many of us can't. I won't regurgitate all the permission based reasons why, as you have heard them many times before. WinUI for Desktop seems to be the option where we can finally move our full-trust desktop applications into UWP flavor XAML and for that reason, previews are what we have to live with.

This pent up frustration isn't directed at any one person or team, not Ryan, but rather the last 8 years of providing half-baked options to write powerful desktop applications. The best option is still WPF. If WPF XAML was compatible with UWP XAML, the effort would be easier and for that reason, I don't want to continue to write hundreds of WPF XAML files. (BTW, now when I joke about all the flavors of XAML I can include Scenic. That was good information Ryan, I did enjoy the presentation.)

[pjmlp]

@jtbrower As things currently are, specially given the unclear roadmap on Project Reunion side, where they just ask for what we would like, once again a survey about AOT instead of clear message on .NET Native, I am sorry for the ongoing WinUI team efforts, but from the outside I would rather stay on WPF.

Still too much WPF features missing from WinUI, if you need to use C++ alongside .NET, C++/WinRT tooling is rather poor versus C++/CLI and C++/CX has been shown the door.

As I mentioned on some community feedback, there needs to be a clear statement that we aren't going XNA, Silverlight, WinRT UAP, ...once more, specifically when projects like Skype and Teams drop WinUI for Electron.

[AathifMahir]

Let's forget about Project Reunion and Win Ui 3, What's the future of UWP? Are we going to see .net 5 support ,performance improvements, New features, etc..

[stevenbrix]

@jtbrower thank you for sharing your difficulties in debugging. Regarding the xaml parse exceptions, this seems to have gotten worse compared to UWP (at least from what I can remember) - can you please file an issue?

As for the xaml compiler running out of memory, that's not something I've seen. How much memory does your machine have? I'm curious if you're running out of machine memory, or if VS is hitting the 4gb limit due to it being 32 bit.

[jtbrower]

@stevenbrix Hi Steve, thanks for the kind response, you are always so helpful.

Compiler Memory Issue

My laptop has 128 gig of ECC protected memory (Dell was having a sale, LOL). When I use the process explorer to show live graphing of memory while using Visual Studio, it was only listing 2.5 gig in use when the targets file reports the out of memory condition. Trying to avoid my love for the memory hungry ReSharper, I recently downloaded and installed a competitor of that tool. Although I cannot blame their tool just yet, the out-of-memory warnings from the targets file began near the same time I installed that extension. I disabled it the other day, but need to spend more time compiling before I can see if its related. Usually when Visual Studio runs out of memory, it goes down instantly. Hard crash, no warning or anything.

Debugging Problems

The XAML parse exceptions are an absolute nightmare. Out of every XAML error I have caused myself so far, not a single exception message has pointed me in the right direction. I will log an issue.

I am not sure if I will Continue

At this point, the cancellation of the September preview might be the inflection point that caused me to halt the WinUI migration. Its a really tough decision and a risky gamble for me to continue to make. It's just entirely too early for a WPF application developer to move over to WinUI. IMO the previews should be entitled betas and the WinUI team given the time they need to make a quality product. I can certainly appreciate what they must be going through trying to develop this out in the open. Sometimes developers are pushed to release code far before they are ready and when that happens you cannot blame any of the team members for a lack of effort. It slows development down to a crawl because your addressing issues that make you feel like "of course they reported that, I said it wasn't ready yet".

I knew I was jumping the gun by trying to force this. Its just that I have wanted so badly to move towards a framework that was being actively developed and improved upon. If WPF would render faster and some XAML syntactic sugar was added (x:Bind) many of us WPF product developers would be less eager to move a mature application into a preview UI framework. I think I am leaning 90% chance of dropping WinUI and moving back to WPF today.

[Manuel637]

Interoperability Question: For extensive 3D applications I would like to know if it is easily possible to use the awesome WinUI GUI features in combination with raw DirectX processing so that e.g. the WinUI controls either overlays the DirectX output or the DirectX output is written to a Panel/Control?

[dotMorten]

@Manuel637 It is! Jump to the 18:30 point in this presentation to see my demo where I do exactly that! https://channel9.msdn.com/events/Build/2020/INT116?term=winui&lang-en=true
The control I use is the SwapChainPanel control.

[pjmlp]

@Manuel637 It is via SwapChainPanel, the caveat is that you will be forced to use C++, as there isn't any MS support to do it from . NET directly.