👨‍💻☎ WinUI Community Call: January 19, 2022

[gabbybilka]

This live event has now ended, but you can view the recording on YouTube at the link below. If you didn't get your question answered, feel free to open it up as a question on this repo. Thanks all for joining!

https://www.youtube.com/watch?v=k6WJmymqNKE

Details

Date: January 19th, 2022
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

The community call is a call among the WinUI team that is live-streamed onto YouTube. We present on new updates, share information, welcome guests, and answer your questions. In this month's call, we'll be sharing WinUI roadmap updates, the latest info about the WinUI 3 Controls Gallery, and an overview of the recent Axe (automated accessibility) testing integration in the WinUI 2 project and how you can add it to your applications.

Agenda

• Intro
• WinUI 2 & 3 roadmap updates and upcoming releases
• WinUI 3 Controls Gallery latest updates
• Axe Testing for WinUI 2
• Q&A
  • Questions and topic requests can be pre-submitted by commenting them on this GitHub issue
  • Questions can be asked live in the YouTube livestream's comment section

Q&A Code of Conduct

• To help ensure Q&A remains beneficial for the majority of the call's developer audience, please consider whether your question could be framed so that it might be more broadly relevant to our larger developer audience by ensuring it is reasonably concise, broadly beneficial, well-suited for the fast-paced live Q&A format, or able to spark open ended discussion.
• Please understand some questions are not well-suited for the fast-paced live Q&A format and should be filed as standalone Discussion or Question issues where they can be most appropriately handled. Excluding presentation topic requests, this generally includes requests for dedicated follow-ups or technically complex questions that require investigative time or expertise not included in this month's guest list.

Leave us your questions in the comments on this issue or live in the YouTube chat during the stream!

[harvinders]

It is noticed that lot of issues are not triaged since middle of November. I am afraid leaving it for too long means if clarification is required from authors, they may not be able to provide the details (they might have moved on, found a work around etc) when the team tries to resolve them. This may lead to closing the issues, leading to missed opportunity to improve WinUI.

Also, it would be a great to hear what plans the team have to look at the ever-increasing number of issues raised in the repo.

[DHancock]

Please could you let us know if application window title bar customization will be implemented on Win10 and if it is, the release that it is intended to be included in? The road map is too high level for that detail, but it's quite an important differentiator between WPF (via chrome) and WinUI3.

[rcohn]

Hello -

Are there plans to address the lack of Xaml tools support in WinUI3 for C++/WinRT desktop apps? Currently, using Windows App SDK 1.0 for C++/WinRT, there is no support for Xaml element properties, no Xaml designer, and no Toolbox support. This problem is severely impacting the ability of my team to make effective use of WinUI3 in an on-going project. I note that WinUI3 C#/WinRT has the same Xaml tools support problem. I have verified these problems on both VS 2019 and VS 2022.

Without this support, Xaml development is effectively reduced to simple Xaml text editing, making it very difficult to easily provide stub event handlers, drop in elements, and adjust element properties at design time. Difficulty in finding good code examples with this framework makes this problem even more challenging.

If there are no plans to address this lack of Xaml tool support in the near future, then what options would you suggest as workarounds?

Thank you very much.

[nikolayvpavlov]

Hello,

What about WinUI performance? In general, WinUI apps don't feel snappy.

See issue: #1633 (comment), which is open for two years? Efficient binding is of absolute importance and if such an issue is not addressed for two years, it is a very poor message to developers.

Worse of all, WinForms, WPF and UWP were all way more-feature complete and stable on their first release. Compared to them, Windows App Sdk 1.0 / WinUI 3 is a disaster. Too many features are missing, the tooling is basically absent and buggy, release roadmap is a outright insult. Would that be a third-party product, it would be immediately dead in the water.

[pjmlp]

@rcohn They killed C++/CX in 2015 with the excuse that they would wait for ISO C++ to support reflection (who knows when it will ever happen) before doing anything to replace C++/CX tooling, in all these years they hardly improved the MIDL experience beyond what Visual C++ 6.0 was already capable of in 2000, so I wouldn't have great hopes in that area.

[pubtom]

If you need .NET>5 in UWP please give a vote on this: https://developercommunity.visualstudio.com/t/Add-NET-678-support-to-UWP/1596483

[AzAgarampur]

When will desktop programs made with WinUI 3 have support for Mica and Background acrylic, and proper titlebar customization? Titlebar customization as of now is very broken; button styles are completely different from the DWM and ApplicationFrame windows that Windows 10/11 use.

Also when will we have a smooth resizing experience? Resizing a WinUI 3 window is jittery and laggy, it should be like UWP ApplicationFrame windows, where it is smooth with no jumps/jitters.

[lukeblevins]

Has the fix for the OS bug related to TabViewItem memory use shipped yet? If not, is there a timeframe for when this will ship?

Context: #3597 (comment)

[dylech30th]

If the XAML designer is still not on the roadmap, please provide a convenient way for customizing the style of the build-in controls, this is very vital during my development, as far as I know, the only way to overwrite the style for built-in controls is to find and modify their source code in this repo or in the windows SDK directory which is both inconvenient(it's a hard job to find the correct source) and error-prone (This repo is actually the code base for WinUI 2, not 3, and there are a lot of differences between them, sometimes just copy codes directly from this repo won't work).

[LPBourret]

Any update on when we can expect MediaPlayerElement support? This is required for any video playback and camera preview viewing to be implemented using WinUI.

[MUJaCHe66]

Any info on creating Win11 widgets ?

[MEK3DK]

Almost all of the above questions point to the same: What resources do Microsoft allocate for WinUI 3?

It seemed like WinUI 3 was to be the new leading UI framework after Forms/WPF but as the other question mentions even basic functionality is not in place now in release 1 or on the roadmap. The list of bugs is huge and Microsoft does not even allocate resources to go through the issues that are filled.
Using WinUI 3 for a business level application is not possible atm, unless it is a very small limited one.
At this speed WinUI 3 either seems to die out due to lack of features/broken stuff, so what is the plan? Is WinUI 3 only intended for small hobby apps or?

[Marv51]

Could you give us an update on Drag and Drop support? Does this work for some people? For us, we experience a crashing bug at unpredictable but frequent times (#4574). We are using it to drag and drop things inside of our app.

[Marv51]

What is the recommended way WinUI applications should take to report crashes to it's developer?

We have a C# application that is installed outside of the Microsoft Store.

Tools like AppCenter only see a small minority of crashes. Maybe because they only catch managed exceptions and not native C++ exceptions? Native C++ crash reporting tools (like Crashpad) are very complicated and assume that we are building the native code ourselves.

For a sideloaded application (even with public code-signing certificate) Microsoft does not seem to collect and/or provide crash reports. (Maybe I am missing how?)

For inspiration look at the Electron API: https://www.electronjs.org/docs/latest/api/crash-reporter

[WelterDevelopment]

It seems that WinAppSDK updates are only released when they previously have been added to a colorfully designed roadmap. This was the case for all previous releases of Project Reunion / WinAppSDK. Keeping that in mind, I am quite concerned that the next release (1.1) is in "Q2" 2022, meaning that we have to wait some 3 more months to get trivial fixes to simple issues like #6194 (only as an example, there are hundreds of other probably simple to solve bugs filed as issues). That is just unacceptable because version "1.0" is far from stable but advertised as best practice tool instead of UWP development. So:
-> Why don't you "discipline" your routine and implement a fixed monthly update schedule? What I want to see is at least 2 production ready (not pre-) releases (e.g. 1.01, 1.02) before 1.1 is released. This way easy, important and urgent (Eisenhover Matrix) bug fixes can be quickly resolved and you would do everybody a huge huge favor and we would'nt be that "disgruntled", to put it mildly.
-> Would it help you to decouple WinUI 3 releases from WinAppSDK releases? If yes, why aren't you doing that? I wouldn't be mad at you if two dependencies have to be referenced instead of one :)

[WelterDevelopment]

With your current behaviour and communication, I see that you build up a crowd of "haters" and in general bad publicity (see e.g. this article and its comments: https://www.theregister.com/2021/11/29/windows_app_sdk_10_is/).
-> Do you fear that as a result of the way too early published Win11 and the way too early published WinAppSDK 1.0, the WinUI 3 development (and .NET desktop development as a whole) experiences a significant loss of trust? If yes, what is your short-term and long-term strategy to work against it?

[ackh]

Are there any plans to support compiling C++ WinUI 3.0 apps with Clang in the future? I've submitted a proposal for this last August but no one from Microsoft responded to this proposal so far.

[Marv51]

I know it's been a topic multiple times: open-source

Is it in the cards for 2022?

I feel like a simple 'drop' for each release would already be pretty useful. If I could build my own version from source that would be great.

For me accepting pull-requests, automated-testing and code-quality are topics that can be addressed separately.

I would accept pretty large closed source binaries that get downloaded during build. For me this is not about philosophical openness, but simply about developing workarounds for the bugs I care about and getting them fixed asap.

[tinmac]

The WinUI 3 in desktop ContentDialog seems to be getting new features, one of which is for it it to operate as a modal dialog as per this github issue

• is this happening & if so when can we expect it?
• is there a github issue where can we track this? (the one above is old)
• & what is the current state of development?

[dylech30th]

When can we have better support for exception diagnosis? For now, we can check the exception message at the Output window, however, it is much less efficient than directly looking at the exceptions' popup window, not to mention that the Windows App SDK 1.0 is so-called "production-ready", finding some lines of exception log in a huge amount of texts in output window is a tedious job. We need better diagnosis support

[kmgallahan]

@dylech30th

Hitting an exception and trying to debug where it came from is often a nightmare. Just hit

WinRT originate error - 0x80070057 : 'The parameter is incorrect.'.

From this friendly catch-all:

Solong hours of my life as I try to figure out what line of code it came from.

And yes, sifting through the wall of unhandled native vexing exceptions used for control flow in WinUI is always a pleasure.

[pjmlp]

@dylech30th For the same reason they call production ready a C++ development experience akin to using COM before .NET was released into the wild, 20 years ago.

That is what we need to mess with every single time we need to use "modern" APIs not exposed to .NET.

[rcohn]

Hello -

I have been seeing a NavigationViewItem behavior in Windows App SDK 1.0 that was not present in Project Reunion 0.8.5. Namely, when an item is underlined (normally a blue line), the line is being truncated. The expected behavior (I thought) is that, for a horizontal NavigationView, the line beneath a NavigationViewItem should be as long as the displayed text.

Here is an example of what I'm talking about:

When can we expect a fix for this?

Thank you.

[Marv51]

@rcohn Your screenshot does not show anything broken. The selected item in a navigation view has an indicator marking it as active. It is in the users accent color by default. You see this for example in the Windows 11 settings.

[harvinders]

@gabbybilka @MikeHillberg Is there any update on #6076, the TabViewItem header visual issue? Would it make it into the service release? This is the one issue that is preventing us to release the application to wider audience.

[kmgallahan]

@harvinders I'm pretty sure the original attempt to solve that problem caused the issue with unexpected gradients while setting rounded corners. #6194

[niels9001]

Would be great to have some updates on:

• Multi-window support
• Elevated (admin) support
• Estimated turn-around time on the many un-triaged issues :).

[WelterDevelopment]

I understand that WinUI 3 is decoupled from the operating system. But W10 uses Reveal Style as the default and W11 uses the [Iactuallydontknowhowitscalled] Style as the default. If I target W10 and W11, why is'nt the DefaultStyle falling back to the corresponding RevealStyle in W10? An app in W11 looks exactly the same in W10 and W11. Is that actually intended by Microsoft? Or is it up to the developer to implement their own Reveal Style in the W10 version and the whatever Style in the W11 version?

[rcohn]

@rcohn Your screenshot does not show anything broken. The selected item in a navigation view has an indicator marking it as active. It is in the users accent color by default. You see this for example in the Windows 11 settings.

@Marv51 - the length of the underline is definitely too short. My comment was not on its color or whether it indicated the active tab. I am amazed that you did not actually address my concern.

[Aaron-Corp00]

@harvinders I agree the lack of issue triage is concerning.
@rcohn The lack of a WYSIWYG XAML layout editor is why I can't really consider this framework to be a valid replacement for WPF. The team I work on considers this to be a large issue.
@MEK3DK I think the feature set is largely okay for business applications, but the number of issues in a triage state and reported bugs is concerning. I am also concerned that there are not enough people allocated to the work on this framework.

@gabbybilka I appreciate the work that you and your team are putting into WinUI3. I'm looking forward to the next roadmap update. Unfortunately, my team is having a meeting tomorrow to determine if we switch from WinUI3 back to WPF.

I think there are many good things in WinUI3, and it has good promise, but ultimately in its current state I question its viability for production level applications.

[kmgallahan]

@rcohn Recently stated that this is by design:

#4873 (comment)

[seven-mile]

Hey guys, is the next call due on Feburary 16th? Curious about your progress in 1.1!

[tinmac]

Hey guys, is the next call due on Feburary 16th? Curious about your progress in 1.1!

Not happening in Feb, March is next one
#6726

[michael-hawker]

@gabbybilka would it be possible to have the Q&A portions of the calls transcribed and added as a summary to the end of each of these issues? Would help folks who can't make the calls to find out what was discussed at a glance and make it searchable here with the rest of the issues on GitHub.