Can we talk about support for nullable data types in controls and default values? As an example there is DatePicker which returns DateTimeOffset and CalendarDatePicker which returns DateTimeOffset?.

• Why is one of these nullable while the other is not? Is this because DatePicker was developed using earlier API's in the Windows 8 time-frame?
• Should we consider adding a configuration property to allow/not-allow null in controls?
• Should a DefaultValue property be considered for new controls such as NumberBox, should NaN be kept as default, or should we switch to a nullable double with the default null?
• Are there WinRT/OS XAML limitations with returning and supporting nullable values that would prevent making NumberBox's Value property nullable? If so, how was CalendarDatePicker implemented?
• This is directly related to the NumberBox discussions in #1721 and #1708

Also, what is the roadmap for fixing the open issues on the NumberBox that do not depend on WinUI 3.0? It would be great to start using this control around WinUI 2.4 instead of having to wait longer. It's not fully baked yet in my opinion and I'm uncomfortable pulling this into production apps.

Another interesting idea to discuss I've wondered about: What will Microsoft's policy be on breaking changes now that WinUI 3.0 is going open source?

In the past, Microsoft has virtually never made breaking changes. This is generally a good thing until all the clutter builds up after a few (or 10) years. It's also not the standard for open source projects. For example, eventually ListBox should be phased out for ListView and MessageDialog phased out for ContentDialog, etc. I'm sure there are lots of nicer little clean-ups in the API as well.

I know businesses hate changes -- for good reason. There also MUST be a relatively easy (functionally equivalent) drop-in replacement available to make porting to new APIs straightforward. This would need to be evaluated on a case-by-case basis and a judgement call made.

I'm wondering if we could establish major releases (WinUI 4.0 for example) as allowing breaking changes. This will allow the project to continue to grow without having to live with all past mistakes. Essentially, Microsoft has already decided to do this with .NET 5 by basing it on .NET Core and dropping what was the full .NET Framework.

This might be good to document once it's discussed.

Based on progress made since the last call, when does the team realistically think WinUI 3 will be ready for release:

• Build 2020 (Apr-May)
• Ignite 2020 (Oct-Nov)
• ~2021

Also, how dependent is your work on the .NET team putting together a new AOT solution and .NET 5?

Lastly, is there pressure on the Windows side to have it ready for Windows10X release and/or prior to that for developers to make specialized apps?

Will there/should there be a tool to easily convert WinUI 2.X projects to WinUI 3.0 (since doing this manually might be a lot of work for large projects)?

The Elephant in the room - WinRT (#1856)

The Elephant in the room - WinRT (#1856)

A non-sandboxed app model is coming - which will run in the same way as WPF (including Win32 APIs), but with access to modern WinRT APIs, and open sourced UI and controls with the new XAML running on Direct X 12.

A non-sandboxed app model is coming - which will run in the same way as WPF (including Win32 APIs), but with access to modern WinRT APIs, and open sourced UI and controls with the new XAML running on Direct X 12.

Wow. Wow Wow!!!!

That is beyond amazing! Do we have an ETA for this, will it be discussed in the call?

It's insanely awesome!

A non-sandboxed app model is coming - which will run in the same way as WPF (including Win32 APIs), but with access to modern WinRT APIs, and open sourced UI and controls with the new XAML running on Direct X 12.

Wow. Wow Wow!!!!

That is beyond amazing! Do we have an ETA for this, will it be discussed in the call?

It's insanely awesome!

It was the first thing we learned about WinUI. ETA is for this year, I suspect a definite date will be given at //Build/ - but feel free to ask during the call.

https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md

@jtorjo See the WinUI roadmap. Also see https://github.com/microsoft/microsoft-ui-xaml/issues/1045 for more info (such as VS project templates).

@mdtauk @Felix-Dev I'll re-read those docs. I do remember asking this before - as long as I can easily use win2d from my (non-sandboxed) app, I'll be more than happy!

@jesbis Sorry for the noob question - how do i join the call?

We're setting up the info for tomorrow's call later today - I'll post the directions in a few hours.

The delay is because it's our first time using a new broadcast system - after this it should hopefully go smoother and be ready earlier 🙂

I just had an interesting thought (to me anyways).

Glancing at today's ASP.NET Community Standup livestream I saw essentially 4 MS devs doing a livecoding stream, although it was more of a tech demo. I also occasionally tune into @csharpfritz on Twitch who does full on live coding sessions.

So my thought was - after WinUI 3 is released and the codebase (or most of it) is all open source, would any team members be up for occasionally livestreaming some of their work on WinUI?

It would be a good opportunity to grow WinUI exposure, help people casually explore the codebase, and questions could be fielded once in a while. ~I wouldn't recommend full on chat engagement all the time as that would be super counterproductive, but maybe a Q&A once in a while.

I have no idea what MS policies are on that type of thing, especially during the workday. Would be interesting to hear your thoughts.

Here's the YouTube live event link for tomorrow!

https://youtu.be/MXTVqgB4rW0

Thanks for all the comments and questions so far! We'll try to get to everything, or keep track for a followup if we don't have time.

Is there anything in the guide about performance / fps of the ui? One of the biggest gripes I have with modern Windows 10 is that on a machine like Surface Book you get some awful performance on high DPI displays, made even worse when you combine transparency and additional monitors. It might be out of the reach of what's possible, but is there any considerations here about how fluid and well it performs, especially under these conditions?

Please consider bumping up the priority of borderless/transparent windows (a la https://github.com/microsoft/microsoft-ui-xaml/issues/1247). This is a WinUI adoption blocker for apps, like ours.

cc: @crutkas

Please consider bumping up the priority of borderless/transparent windows (a la #1247). This is a WinUI adoption blocker for apps, like ours.

cc: @crutkas

This would probably require there being a Top Level Window element added to the WinUI Xaml with properties, similar to WPF. #1323

Learning more about the 'future of windowing' for WinUI would be nice - there are a lot of related requests that would be nice to atleast discuss/address.

Probably have been asked before.

To me, is always been a matter of code reusability.
This leads to two questions:

1. Is .NET Core 3 and C# 8.0 support coming anyone soon?
2. Are we going to see further steps from the UWP/WinUI team to make it easier to develop Uno Platform apps?

Another one, when will we be seeing the missing bits from WPF supported in UWP?

Probably have been asked before.

To me, is always been a matter of code reusability.
This leads to two questions:

1. Is .NET Core 3 and C# 8.0 support coming anyone soon?
2. Are we going to see further steps from the UWP/WinUI team to make it easier to develop Uno Platform apps?

Another one, when will we be seeing the missing bits from WPF supported in UWP?

.NET Core code should work on both, so a WPF app would only need to change UI Xaml and UI code.

UWP apps should work fine with a namespace change for WinUI 3.0 - breaking out of the sandbox may need more work, the details are still unknown.

WPF missing bits have not been confirmed, but I made an issue about it. #719

@weitzhandler

Although it isn't officially supported and not all of the C# 8 features will work, you can already use most of C# 8 with WinUI/UWP. See here.

I do this and haven't run into any issues. "Default interface members and Indices and ranges" appear to be the only missing bits, although I haven't tried everything.

Just amplifying what kmgallahan said about using C# 8. I've been using many of the new features, but really wanted Default Interface Members, which aren't implemented yet.

Thanks folks.
If I may still add, old csproj type is also kinda annoying.

@jesbis

I just opened this issue over in the XAML Controls Gallery. It could be something to discuss during the call if you'd like.

Thanks, we'll try to get to all the questions!

Is there anything in the guide about performance / fps of the ui?

@ryvanvel we have some performance guidance here:

https://docs.microsoft.com/windows/uwp/debug-test-perf/performance-and-xaml-ui

And some other blog posts and videos which might help, e.g.:

https://blogs.windows.com/windowsdeveloper/2015/10/07/optimizing-your-xaml-app-for-performance-10-by-10/

https://channel9.msdn.com/Events/Build/2015/3-698

https://channel9.msdn.com/Events/Build/2017/P4173

This bug has been with Windows 10 as far as I can remember, I hope it gets addressed sooner: https://github.com/microsoft/microsoft-ui-xaml/issues/597

Unfortunately I won't be able to tune in on time, will there be a recording?

Edit: the recording of the call can be found here: https://www.youtube.com/watch?v=MXTVqgB4rW0

@jesbis here:

Here's the YouTube live event link for tomorrow!
https://youtu.be/MXTVqgB4rW0

Following the YT link, looks like it's only gonna start at the end of this hour, an hour later than the regular time, is that true?

@weitzhandler The start time is at the top of the post. This is also only the 3rd call, so "regular" is a stretch.

@weitzhandler I'm pretty sure all three calls so far were scheduled to start at 9AM Pacific time.

Thank you two and sorry for the bother. See you soon.

I was curious to know whether the Chromium-powered WebView2 will also expose an event like WebResourceRequested from the current WebView, to let developers filter out individual web requests. I rely on that specific feature a lot in one of my apps and I was wondering whether that would still be around with the new control, and working the same way.

Thank you guys for all the hard work! 😄🚀

Will there be any tool for generating PDFs? Win2D has already a lot of amazing tools, capability to generate PDF from CanvasRenderTarget will be a great addition.

didn't get it - how to install the vsix? where to download?

Maybe it’s just me, but I was disappointed with today’s call. Please include more technical people. PM should keep the discussion focused and moving to schedule but delegate the responses to experts (as was done more towards the end).

I'm guessing everyone on this call are developers and we need to know and discuss the details. PM’s are focusing on very basic topics and are not able to get into the details. For example, the discussions at the beginning of the call about documentation/WebView/ProgressRing are nice in concept but so very basic it isn’t useful for us I think. We've been using XAML for years/decades and you are speaking to an expert audience (it's important to adapt presentations to the audience).

@SavoySchuler Paraphrasing you essentially said tell us how we are using the controls, include our company, and our apps. You need this to separate material needs vs nice to have. This helps you prioritize resources on features. You need to think about this differently for two things:

1. Features -- In this case what you said is largely correct
2. Bugs/Issues -- In this case, no, you don't need the community to give you examples to help prioritize. When delivering any product, quality is your number 1 priority. We are telling you the bugs and you are saying, well, yea, that’s a nice to have. Prove you need it fixed. It’s a bug. Maybe you never shipped apps to consumers? Any little things wrong AT ALL affects your image and perception which is the most valuable part of a company. The App industry is very competitive.

Once bugs are reported by the community you should schedule them to be fixed. Stop shipping incomplete controls with no plans to fix them. This is starting to sound very familiar – it’s what happened with UWP years ago.

In the call, I brought up windowing twice and it was mentioned that:

• this is actually being worked on for WinUI 3 (despite issue being frozen https://github.com/microsoft/microsoft-ui-xaml/issues/1247)
• the Feature Tracking project (updated yesterday) (https://github.com/microsoft/microsoft-ui-xaml/projects/4) is only tracking WinUI 2 stuff???

Can we get some clarity here? Is there another location to see the WinUI 3 backlog? It's super critical for planning purposes that we know what's coming and what's not. Thanks!

@SavoySchuler @jesbis and the rest of the lovely WinUI team, I personally want to thank you for your great work and massive efforts and tell you how grateful I am for making WinUI so awesome and also for answering all my questions.

Huge thanks to everyone who was able to tune in!

And sorry again for the audio and Teams issues - we think we identified a hardware problem and will hopefully have everything sorted for next month.

The recording is live now too for anyone that couldn't make it.

We're looking through the questions and will try to get to anything we missed in this thread.

Some question catch-up:

Will there be any tool for generating PDFs?

@MuziburRahman

We won't have time to get to this for WinUI 3.0 RTM but we're tracking this in the backlog with #672 - feel free to add a comment to that issue on how you would use it!

how to install the vsix? where to download?

@hannespreishuber

The WinUI 2.x usage instructions for production apps are here: https://docs.microsoft.com/uwp/toolkits/winui/getting-started

The WinUI 3.0 Alpha instructions to install and try out the vsix are here:
https://aka.ms/winui/alpha

Maybe it’s just me, but I was disappointed with today’s call. Please include more technical people. PM should keep the discussion focused [...] We've been using XAML for years/decades and you are speaking to an expert audience (it's important to adapt presentations to the audience).

@robloo thanks for the feedback on this. We can include more devs and do more deep-dives on specific topics for future calls if that's of interest to everyone - we didn't want to try that for the first call since it's been a while and we wanted to do a general catch-up.

We've also had feedback in the past that sometimes we get too technical and too in-depth because a lot of the audience isn't super familiar with WinUI yet - so we're trying to balance that feedback too.

Also, if it helps to note: many of our PMs on the developer platform teams are super technical and have experience writing production code for major platforms and real apps. Some of them were previously full-time developers at Microsoft and other companies. We also still write code all the time as PMs, it just isn't our sole focus 🙂

Finally, on bugs and quality: quality is super important to us and we spend a lot of time on bugs, tests and quality infrastructure. You can see the ratio of quality fixes vs. new features in the commit log for WinUI 2, and once it's open source you'll be able to see the same for WinUI 3. That said, no major codebase is bug-free and we always have to balance business priorities.

If controls seem incomplete then please do open issues for them.

In the call, I brought up windowing twice and it was mentioned that:
this is actually being worked on for WinUI 3 (despite issue being frozen #1247)
the Feature Tracking project (updated yesterday) (https://github.com/microsoft/microsoft-ui-xaml/projects/4) is only tracking WinUI 2 stuff???
Can we get some clarity here? Is there another location to see the WinUI 3 backlog? It's super critical for planning purposes that we know what's coming and what's not. Thanks!

@riverar that project board is currently for WinUI 2 since it's the only code in the repo currently.

We use the needs-winui-3 label for issues that will have to wait for WinUI 3 before they can be properly addressed, but we don't have public tracking for our WinUI 3 work yet.

We'll continue to post feature proposals for major items - like the Chromium WebView spec in the separate specs repo:

https://github.com/microsoft/microsoft-ui-xaml-specs/blob/master/active/WebView2/WebView2_spec.md

and once we're able to open-source WinUI 3 Xaml we can start moving tracking to GitHub, but the bulk of our day-to-day workitem tracking will realistically likely remain internal through the development of 3.0 for various reasons (we have lots of private OS dependencies to untangle, need to interface closely with other OS component dev teams, etc.)

I can say though that most of those tagged feature suggestions won't be addressed for the initial 3.0 release - our main focus areas are:

• getting WinUI decoupled from the OS and shipped separately
• open sourcing the Xaml framework
• creating a good WinUI desktop app development experience (win32 usage, packaging, windowing, etc.)
• enabling Windows 10X
• enabling .NET Core/5 + WinUI apps

and we don't want to delay or destabilize that by trying to do a ton of additional new feature development at the same time.

As we make concrete progress on big areas like desktop/windowing support we'll post proposals and updates to the repo.

and once we're able to open-source WinUI 3 Xaml we can start moving tracking to GitHub, but the bulk of our day-to-day workitem tracking will realistically likely remain internal through the development of 3.0 for various reasons (we have lots of private OS dependencies to untangle, need to interface closely with other OS component dev teams, etc.)

Would it be possible to list these internal work items publicly, even if they appear as blank entries with some generic name like Internal Issue? Seeing these move from To Do, through to In Progress, and to Complete - would indicate some degree of progress for the project entire.

I can say though that most of those tagged feature suggestions won't be addressed for the initial 3.0 release - our main focus areas are:

• getting WinUI decoupled from the OS and shipped separately
• open sourcing the Xaml framework

This is of course the core of the endeavor, but it may be possible to solve various problems or issues with the current implementation, as it is being extricated from the OS code.

• creating a good WinUI desktop app development experience (win32 usage, packaging, windowing, etc.)
• enabling Windows 10X

This will be essential to get right, and will require getting both of these things into the hands of users and developers, with an open mind to accept feedback. It will also be difficult because the app runtime and app modal are not owned by this WinUI team, and so enabling feedback to filter to those in charge of them, needs to be put in place.

• enabling .NET Core/5 + WinUI apps

Current Native support comes in the form of C++ code, and Win32 APIs - but does this mean any C# developers need to target .NET? Will the non-sandboxed app model allow for C# coding without .NET?

and we don't want to delay or destabilize that by trying to do a ton of additional new feature development at the same time.

As we make concrete progress on big areas like desktop/windowing support we'll post proposals and updates to the repo.

Without the CoreWindow (which will be UWP only going forward) - Windowing is one of those things that will need to be in place from day one. WPF has a Window object in XAML which handles the controls, visual styling, transparency etc. It handles resizing, minimising, etc. Older Win32 frameworks require manual painting of surfaces which are not a thing for XAML UIs - so how does this gap get bridged?

This is before we even get to dual screened devices, and how a non UWP app model and windowing setup would adapt to that.

Would it be possible to list these internal work items publicly, even if they appear as blank entries with some generic name like Internal Issue?

Our goal is definitely to move our processes (including issue tracking) to open source in addition to the code.

As a start, we have a WinUI 3.0 milestone for high-level tracking and as we migrate WinUI 3 Xaml code to open source we'll also open more "feature-level" issues in that milestone.

However that won't include all of our WinUI 3.0 day-to-day dev tasks right away - for reference we're currently tracking thousands of days worth of related dev work for 2020 and we just aren't yet ready to move all of our super-granular tracking to GitHub today. We will get to that over time though, like we did with WinUI 2.

So, we'll start with feature-level issues (like have started so far - e.g. WebView) and will fully migrate our processes to GitHub over time.

Current Native support comes in the form of C++ code, and Win32 APIs - but does this mean any C# developers need to target .NET? Will the non-sandboxed app model allow for C# coding without .NET

Are you asking about .NET Native, or no .NET at all? Technically I think the C# spec as a language doesn't depend on .NET, but we currently have no plans for transpiling to C++ or anything like that.

Without the CoreWindow (which will be UWP only going forward) - Windowing is one of those things that will need to be in place from day one. WPF has a Window object in XAML which handles the controls, visual styling, transparency etc. It handles resizing, minimising, etc. Older Win32 frameworks require manual painting of surfaces which are not a thing for XAML UIs - so how does this gap get bridged?

@marb2000 is working on that and will be able to share more info as available.

This is before we even get to dual screened devices, and how a non UWP app model and windowing setup would adapt to that.

To be clear, WinUI 3 will not be bringing all of win32 desktop to other platforms like HoloLens: universal apps and APIs will still be the way to go when targeting multiple devices.

Posted too early. Full comment:

@robloo - I want to start by agreeing with a lot of your sentiment and I appreciate you bearing with us through our growing pain. I was very much scatterbrained with all of our technical issues and I didn't handled that question as well as I would have liked to. Please allow me to try again here:

Charter and resources

I know treading on any topic like this will never be popular, but I believe in transparency and want to be candid with you as the community about the challenges we face so that you can be part of the discussion in helping us decide how we solve them. This particular challenge focuses of division of times and resource assets. There are three major initiatives our team is divided across:

1. Advancing WinUI 2
2. Delivering WinUI 3
3. Open sourcing WinUI 3

As you know, we're dialed firmly toward 2 and 3 because A) these are coupled objectives and B) open sourcing WinUI means everyone can stop being blocked by our team's finite resources because WinUI will finally be empowered to accept community pull requests.

If we are dialed too forward on objectives 2 and 3 to a point where WinUI 2 is under-serving community members, we can have that conversation and we are open to reprioritizing. Just know that resolving all the bugs in our backlog would delay WinUI 3's release to market by ~6 months. Should we instead prioritize 2 and 3, which not only open sources WinUI but expands its relevancy to our massive base of Win32 developers, we will be able to clean our backlog of bugs _and_ feature requests with the power of the open source community and our team's undivided attention supporting us. To that end, our current rationale is that plan of approach would not only move this platform forward faster but more comprehensively as well. When I asked you to help us prioritize bugs, the question was not "are they important enough for our team to tackle?" but instead " is this important than open sourcing WinUI sooner?" At status quo, we do have a subset of developers working to advance priority 1 and you can their impact in our commit history and active issues, but they face the need to prioritize within that objective all the same. This notion of "tell us how important this is to you" does help us filter needs (e.g., my product is blocked and I can't wait for WinUI 3) vs. niceties (e.g., I noticed this technical error but no existing development is blocked on it so it can wait for WinUI 3).

The other thing I want to say clearly is that all the work going into filing WinUI 2 bugs, filling out feature requests, etc., will _not_ be lost on us. When WinUI 3 releases, we will have a significant subset of our team freed to return to work items that advance the platform on top of empowering the community to submit code as well. This means right now we are priming a backlog that the full force of our team will tackle with the help of our existing UWP community and, soon, Win32 as well.

One additional thing to be aware of is that while we are migrating code from the OS to WinUI 3, we are taking steps to simply and cleanup the code behind where we can. This means certain feature additions and bug fixes will require measurably less time and effort if resolved in WinUI 3.

NumberBox

Features

Let's return to NumberBox. You are factually correct in saying V1 is a subset of the features desired.
Planned V1 features were delayed until V2 due to dependencies on things like input validation (which by the way is in preview in the WinUI 3 alpha). We tried to be complete in our spec by acknowledging everything we think deserved to be V1 in the spec (here) and plan to fully deliver on that commitment with a WinUI 3 V2 release of the control.

By embracing the spirit of open source, my desire (and please tell if I am in error by doing this) is to fully prefer releasing reliable, useful code as fast a possible and to build the feature sets incrementally. In application, this meant preferring to release our _mostly_ complete V1 in WinUI 2 and follow it up with a fully featured release with input validation as we can with WinUI 3.

Bugs

As @jesbis said, no code base is bug free, but quality is absolutely top of mind for us. We are committed to cleaning up bugs and have a subset of the team working to do this WinUI 2. Until our teams full effort is reunited by the release of WinUI 3, this will move slower than our hearts want it to, but we are still working away at it. @jesbis noted, you can see the ratio of quality fixes vs. new features in the commit log for WinUI 2, and once it's open source you'll be able to see the same for WinUI 3.

I remain committed to helping resolve these bugs with NumberBox and I am setting aside the rest of my day to respond to open issues, bugs, and questions where I am able to be an asset. I will set aside a day next week as well. Please feel encouraged to send me questions on Twitter or engage with me about it here on the repo.

Next steps

To us, open source is the promise of embracing the community as team members just as if they were sitting here in our Redmond office. We're hear listening. Let's talk about these decisions together so that we can focus on building awesome stuff as one big team. 🙂

We ❤️ WinUI

By embracing the spirit of open source, my desire (and please tell if I am in error by doing this) is to fully prefer releasing reliable, useful code as fast a possible and to build the feature sets incrementally. In application, this meant preferring to release our mostly complete V1 in WinUI 2 and follow it up with a fully featured release with input validation as we can with WinUI 3.

This could just be me but I feel that while its important to ship code as fast as possible, there are certain types of issues that should be resolved before shipping anything, for example #1846 is something that should of been addressed before shipping V1 and there may be a few others as well.

@yaichenbaum I could have chose my words better there. 🙂

If A-D are _must have_ features and E-H are _nice to have_ features, my priority is to get A-D out the door and incrementally add E-H as able.

The reason we do staging on a preview branch with validation partners is to catch bugs like #1846 before controls get pushed to stable release. Sorry we dropped the ball on this one, I will work with @teaP ASAP to see how fast we can resolve this! 🙂

At one point in the call it was mentioned that WinUI apps would allow sandboxing via AppDomain.

Can someone speak to how WinUI 3.0+ will be positioning Capabilities vs. AppDomain for application isolation and resource control?

Also, the last I knew for .Net Core, full support for AppDomain was not happening.

Maybe I'm out of touch, but are you saying .Net 5 is going to have full AppDomain support?

Thanks for organizing this call today!

Can someone speak to how WinUI 3.0+ will be positioning Capabilities vs. AppDomain for application isolation and resource control?

Sorry if it wasn't clear in the call but I was talking about AppContainer, not AppDomain.

Ah, ok, thanks for the clarification Jesse.

First of all thanks @SavoySchuler and @jesbis (and all the rest of the WinUI team) for organizing todays community call! Though there were some technical difficulties, this call was very insightful !!!

As @jesbis mentioned there is an issue tracking the tools and features requested for WinUI 3.0 . Would it be better to split the request of a WinUI 2.x to 3.0 conversion tool into a separate issue for easier tracking? Also are there already any plans? Are there plans to make the tool open source so other devs can help developing it?

Another more general question (which would also be for other non WinUI team members), is about contributing. Are there any obstacles currently that are preventing people from contributing? Would a better getting started guide for contributors help?

In my opinion, if you start contributing to the project, the VS Project may be a bit overwhelming, and there is not much documentation regarding on how to develop, which test project should be used for what etc...

Maybe improvements in that area would make it easier for people to contribute 😅

How is the WinUI 3.0 rendering layer done? Does it directly make use of D3D11, D2D, abstraction layer or what? Does it have a software rendering layer or make use of D3D WARP for that?

@chingucoding

I'll repeat the points I just made over here:

• Not having used the lang in forever
• No idea how much code churn is happening in the background for the WinUI 3 release that would overwrite changes made today
• No access to a bunch of the source code that would be needed and/or help tremendously in working through issues

Edit: I'll give an example. #1555 and #1849 are seemingly major issues with a core control (TextBox) that are preventing text input and selection while multitasking.

They're high on my list of important issues that should be resolved, but I'd have no idea where to start. Nor do I know if the code I'd want/need to step through to debug things is available.

@SavoySchuler

If we are dialed too forward on objectives 2 and 3 to a point where WinUI 2 is under-serving community members, we can have that conversation and we are open to reprioritizing. Just know that resolving all the bugs in our backlog would delay WinUI 3's release to market by ~6 months.

I certainly understand. However, NumberBox is a bit different here in my mind and I'm certainly not saying we should focus on all bugs. Right now I'll only talk in the context of the NumberBox. Although there are certainly a few other glaring issues that need to be addressed.

NumberBox is a newly developed control for WinUI 2.3 not a legacy control that everyone has to accept at this point. Why wouldn't we do this correctly to start? This is very much a litmus test of the new development model.

If A-D are must have features and E-H are nice to have features, my priority is to get A-D out the door and incrementally add E-H as able.

I completely agree with you here. But you Must understand the difference between features and bugs. It concerns me that you are thinking only in terms of resources/manpower for Microsoft. However, have you considered app developers waste countless hours trying to work around bugs in controls? It is far more efficient to fix these things at the source and also really helps the perception of the platform/tooling.

The other thing I want to say clearly is that all the work going into filing WinUI 2 bugs, filling out feature requests, etc., will not be lost on us. When WinUI 3 releases, we will have a significant subset of our team freed to return to work items that advance the platform on top of empowering the community to submit code as well.

Microsoft has a really bad track record of releasing incomplete software and then moving on to the next latest-and-greatest tech before having a chance to complete the last. Please forgive me for being skeptical of your promise.

Let's return to NumberBox. You are factually correct in saying V1 is a subset of the features desired.
...By embracing the spirit of open source, my desire (and please tell if I am in error by doing this) is to fully prefer releasing reliable, useful code as fast a possible and to build the feature sets incrementally.

Totally on the same page with you in terms of features. Bugs are different. You need to address bugs differently than features and commit more resources to them. It just looks bad to release a brand new control like NumberBox and then say you can't commit resources to fixing bugs until a year from now.

I'm asking you to address the bugs in V1 of the control that do not depend on WinUI 3.0. Some are fairly basic and others are glaring mistakes in design (like NaN crashing two-way bound data). Once you commit to releasing a feature/control you must then quickly work to close the bugs. There are ALWAYS bugs when software has it's first wide-release you just need to plan resources to do a quick bug-fix V2 (like the rest of us app developers). As we agree quality is a top priority, please fix the following issues with NumberBox before going on to other things.

1708 - Placeholder text is absolutely required with any form usage of the control and one of the basic features already in the spec. If this has indeed been fixed for NaN we should close it. Null support is a different topic below.

1721 - A big issue with UWP was it's incomplete support for data binding in certain controls. A lot of application developers invested in MVVM design years ago and then trying to jump over to UWP controls discovered data binding was only partially supported. This is a huge pain point and is unacceptable considering how fundamental MVVM is to Microsoft's best practices. The old windows developer tooling team would never stand for this -- this is Windows/native thinking here.

1839 - Basic stuff here. These are just basic bugs in the control template and MUST be fixed. No excuses.

1846 - We've had this issue in so many other controls previously. Why isn't there a release checklist that tests for this by now? Again, basic stuff that needs to be fixed. It affects usability of all apps that use this control.

1852, #1853, #1854 - Again, these are not overly complicated and were just missed in the first implementation. However, it is a legal requirement to support accessibility in software sold in certain regions or developed for the government. As a platform you should fix this immediately so application developers can use the control. Again, I shouldn't have to debate this type of thing with you, it's basic stuff.

One additional thing to be aware of is that while we are migrating code from the OS to WinUI 3, we are taking steps to simply and cleanup the code behind where we can. This means certain feature additions and bug fixes will require measurably less time and effort if resolved in WinUI 3.

Understand at a high-level. However, fixing the above issues isn't going to delay WinUI 3.0 for 6 months. They also do not depend on WinUI 3.0 to address (except potentially for #1721). You are setting a dangerous precedent by releasing NumberBox and then not sticking with it to close the first round of bugs. You should have learned this lesson already with UWP itself.

Maybe improvements in that area would make it easier for people to contribute

Would love to contribute. Do not love working with C++/WinRT and certainly don't feel qualified to touch the codebase as I've seen it. If controls were managed C# you would have had a lot more contributions. I understand why the architecture is what it is, but one of the consequences is less community contributions. We are not system developers here, we are end-user app developers.

RE: contributing:

Another more general question (which would also be for other non WinUI team members), is about contributing. Are there any obstacles currently that are preventing people from contributing? Would a better getting started guide for contributors help?
In my opinion, if you start contributing to the project, the VS Project may be a bit overwhelming, and there is not much documentation regarding on how to develop, which test project should be used for what etc...
Maybe improvements in that area would make it easier for people to contribute

Nothing should be stopping people from contributing to WinUI 2, which is the codebase currently in the repo. If there's a WinUI 2 issue that you want to work on then please let us know and we can assign it over to you!

We have lots of items tagged with good first issue and help wanted if anyone wants to help with items that should be (relatively) easy to start with 🙂

For bugfixes you can just open a PR. If it's a major new feature then then we also have a bit of process to review the issue first to make sure the proposal is a good fit for WinUI.

I totally agree the contributor guide could be better and that it's hard to get started - I recently went through the exercise of trying to follow it to implement a new feature (RadialGradientBrush) and found that it could use lots of improvement - it's now on my todo list to improve the guide.

I'll give an example. #1555 and #1849 are seemingly major issues with a core control (TextBox) that are preventing text input and selection while multitasking.
They're high on my list of important issues that should be resolved, but I'd have no idea where to start. Nor do I know if the code I'd want/need to step through to debug things is available.

Those still need to be triaged (categorized) by our dev owners (hence the "needs-triage" label - I'm currently following up on why they haven't been yet, sorry) but I expect that since TextBox isn't in WinUI 2 those will have to wait for WinUI3.

Once they get triaged they should have the needs-winui-3 label applied which indicates that they'll have to wait for WinUI 3 before we could address them.

Once WinUI 3 is open source then anyone would be able to help resolve those issues too.

Do not love working with C++/WinRT and certainly don't feel qualified to touch the codebase as I've seen it. If controls were managed C# you would have had a lot more contributions.

We know that C++ is a higher barrier than C#, but the plan is that WinUI will remain a C++ platform.

Another great project to contribute to is the Windows Community Toolkit which is easier to contribute to since it's C# and has some relaxed requirements.

We work with the maintainers and often use the Community Toolkit to incubate new controls that eventually migrate to the Xaml platform (which does involve re-implementing in C++).

Does WinUI require C++/CX? If so seems like this is an issue for Win32 and other future targets?

How is the WinUI 3.0 rendering layer done? Does it directly make use of D3D11, D2D, abstraction layer or what? Does it have a software rendering layer or make use of D3D WARP for that?

The WinUI Xaml framework's rendering is primarily implemented on the Windows 10 composition engine. The composition layer APIs will also be part of WinUI 3.

In the end that generally means hardware-accelerated rendering using Direct3D, Direct2D and DirectWrite, with software rendering in some cases where it makes sense.

You can also include your own custom-rendered DirectX content using interop APIs.

Does WinUI require C++/CX? If so seems like this is an issue for Win32 and other future targets?

No - the WinUI platform is written in C++ but your apps definitely don't have to be!

With WinUI 2 today you can create UWP apps using .NET (C#, VB.NET) or C++.

With WinUI 3 our goal is that you will be able to create apps that use UWP and/or win32 APIs using the upcoming .NET 5, or C++.

@jesbis I think you may be misunderstanding my questions intent a little.

1) I know WinUI is written in C++ however does any WinUI code require Windows only VC++ / CX extensions? If it does require CX extensions I see this as maybe causing portability issues down the line if WinUI wanted to expand to other platforms. This might make it hard for the UNO team to adopt code for example.

2) About the rendering system. Couple things here.

2.a) Is the "Visual layer" an abstraction API removed far enough away from DirectX APIs that it could later support a Vulkan backend for example? (I'm sure this question will be answered when the source is released but I'm just wondering)

2.b) My question about software rasterization was more along the lines of: Will WinUI 3.0 support full software rendering (not just text rendering or what-not)? Sometimes screen sharing software has issues with GPU accelerated apps (at least with D3D9 / WPF) and forcing software rendering on fixes the issue in those situations). Or if the app is ran in a VM with no hardware GPU.

The WinUI 3.0 Alpha instructions to install and try out the vsix are here:
https://aka.ms/winui/alpha

did that with Edge New the download link doenst showed up, repeated it with chrome- download there

did that with Edge New the download link doenst showed up, repeated it with chrome- download there

@hannespreishuber the download link should be on the last page of the survey. Do you mean that the survey didn't work in Chromium Edge but did work in Chrome?

the download link should be on the last page of the survey. Do you mean that the survey didn't work > in Chromium Edge but did work in Chrome?

did survey on both - but last page was diffrent, perhaps my fault.

did survey on both - but last page was diffrent, perhaps my fault.

Okay, thanks - we tested the survey on both versions of Edge and it seemed to work so if anyone has problems with the download please let us know, and also report the problem in Edge if page content renders differently than Chrome (Settings > Help & Feedback > Send Feedback) 🙂

I know WinUI is written in C++ however does any WinUI code require Windows only VC++ / CX extensions? If it does require CX extensions I see this as maybe causing portability issues

@zezba9000 we've implemented WinUI 2 controls and features (the new code currently in the repo) using C++/WinRT which is standard C++17, but the rest of WinUI 3 is a much larger and older codebase that will currently still rely on WRL etc. We aren't focusing on portability at this time but are open to discussing it in the future.

Is the "Visual layer" an abstraction API removed far enough away from DirectX APIs that it could later support a Vulkan backend for example? (I'm sure this question will be answered when the source is released but I'm just wondering)

We're not focusing on portability at this time for the visual layer either. There are some loose couplings between the Visual layer and DirectX APIs (not counting implementation) but it's mostly abstracted. Also, to clarify about open source: our initial target for open sourcing code and our day to day development processes is the Xaml framework, which will not include open sourcing the visual layer at this time.

My question about software rasterization was more along the lines of: Will WinUI 3.0 support full software rendering (not just text rendering or what-not)? Sometimes screen sharing software has issues with GPU accelerated apps (at least with D3D9 / WPF) and forcing software rendering on fixes the issue in those situations). Or if the app is ran in a VM with no hardware GPU.

Yes, rendering over screen sharing, in VMs etc. should all work. For most content there should be no visible difference. If you look through the WinUI 2 code in the repo you might also see usage of an API we use to query whether certain effects are supported/"fast" at runtime and fall back to simpler rendering of certain effects in some cases, but apps shouldn't have to do anything special to support software rendering when using default platform controls and features.

I completely agree with you here. But you Must understand the difference between features and bugs. It concerns me that you are thinking only in terms of resources/manpower for Microsoft. However, have you considered app developers waste countless hours trying to work around bugs in controls? It is far more efficient to fix these things at the source and also really helps the perception of the platform/tooling.

Agree 100% - I don't even wanna recall the number of hours I'm spending working around bugs from UWP/WinRT.

Jesse,

I'm primarily concerned about developing enterprise applications. I am currently using WinUI 3.0 Alpha to build a proof of concept to demonstrate how Xaml, GPRC, multiple windows and true multi-threading can offer the business and the business user a more productive application experience.

Why? Because we need an alternative to browser-based/small screen applications. I have lots more to say on that topic, but I'm going to KISS here.

What I would like from the WinUI team and indeed Microsoft is to embrace and support building desktop apps for business.

There were 3 main reasons web apps were adopted in the enterprise so quickly - cross-platform support, security and easy of deployment To be a viable alternative, desktop apps need answers to those questions.

It seems most of the software development industry is focused on delivering applications for the browser and/or mobile/tablet form factor.

Enterprise applications run on workstations with lots of CPU, screen size, memory, storage, graphics and bandwidth when compared with “mobile first” applications. The users of these LOB applications may engage for hours and hours at a time. We need app design guidance to address these factors.

There are other dimensions in enterprise applications that do not get much discussion – longevity and skillset. Again, lots to say here, but I’m going to summarize. Businesses invest money in building applications and they plan to use those apps for a “long” time. This means the underlying technology needs to be supported for decades. I would like to see WinUI be that next long-lived technology to replace Win32/MFC and WinForms.

IT departments constantly struggle with finding SEs with the right skillset. Web tech has made this even more challenging. I would like to see a new stack C#, Xaml and SQL (C#XS) that identifies a focus on building desktop apps.

There is also a minor point I would like to make with respect to styling. WinUI enterprise applications should require a minimum of styling “out of the box” in order to be functional. Also, and this might be directed straight at Fluent, but don’t hide controls (like scroll bars). Business users have plenty of screen real-state and do not care how “gorgeous” a UI is if they do not know there is more on a page.

We need a robust (free) datagrid control. Can’t emphasize that enough.

I have more ideas to share if you’re interested, but I’ll stop here and summarize:

• Microsoft needs to provide a comprehensive desktop application development solution.
• WinUI/Fluent need to address the requirements of the business user such as function/form, UX for desktop, code samples/project templates that demonstrate multiple windows, true multi-threading, data validation, “Form-like” pages.
• Microsoft needs to make it clear they are offering WinUI to build highly productive, long-lived business LOB applications. Also, why .Net 5 + WinUI will NOT be another DLL hell.
• Make it clear that WinUI is the replacement for Win32/MFC and WinForms.
• Push C#XS as a skillset for IT.
• (Free) Datagrid

Hope you found this helpful.

@robloo Rest easy - no debate needed! 🙂 I committed to fixing this lapse in my early comment and that still holds true. I think I also made a mistake earlier by continuing to generalize. Let's talk about the bugs you listed. Two were filed right before our major holidays here (I can't speak for @teaP, but I was offline most of December) and we went through a management change on our engineering side (congrats @ranjeshj!). It's no excuse and I apologize that these two bugs were not attended to more swiftly during these changes and absences. The others listed here have all been filed within the last 10 days or less.

To have it pointed out that NumberBox in particular is a culprit and that these are stacking up helps us be strategic with our time, so thank you for helping us see this. I have scheduled time early next week to review our outstanding NumberBox bug list with our NumberBox dev @teaP and our (newly titled) engineering manager @ranjesh so that we can get to resolving them collectively ASAP.

@SavoySchuler Thanks!

@SavoySchuler , it seems you're stuck in a difficult position of choosing between:

a) Fix bugs in WinUI 2.x, and delay the release of WinUI 3.0
or
b) Leave WinUI 2.x to the community, and dedicate internal resources towards WinUI 3.0 to achieve the earliest release date

I guess that a lot of existing WinUI 2.x users will want you to fix the bugs first, as they are currently affected, but perhaps this could be mitigated by offering a realistic expectation of when WinUI 3.0 _could_ be available, given sufficient resources (and assuming WinUI 3.0 will offer additional fixes over 2.x).

Personally, I would not want to see a delay in the release of WinUI 3.0, and think it's reasonable that the community get involved in solving any issues that are critical in WinUI 2.x (after all, it is open source). Some people have the expectation that because it's Microsoft's project, they should do all the work. Unfortunately that's not realistic, and nor is it how other open source projects work.

@jesbis , it's interesting hearing about the Visual Layer with regards to WinUI 3.0. Are you saying that for the initial releases, WinUI 3.0 will have a dependency on Windows.UI.Composition classes? Is there a possibility to get more features added into the OS to support the Visual Layer ahead of extraction into WinUI 3.0?

For reference, things I'm interesting in:

• Win32 "AppContainer" model. We're fully sandbox compatible on other OSes, but we'd like access to "modern" APIs
• The Visual Layer (Windows|Microsoft.UI.Composition)
• DXGI Swap chains in the visual layer / SwapChainPanel
• Window management APIs (AppWindow etc)

@infoequipt thanks for the in-depth notes! Definitely helpful. @marb2000 for visibility

it's interesting hearing about the Visual Layer with regards to WinUI 3.0. Are you saying that for the initial releases, WinUI 3.0 will have a dependency on Windows.UI.Composition classes?

@MarkIngramUK no, sorry for any confusion - my earlier point was just about open sourcing.

Microsoft.UI.Composition will be part of WinUI 3 and Microsoft.UI.Xaml will depend on it. That's already the case with the WinUI 3 Alpha.

We're working toward open sourcing Xaml, which means the Xaml framework code will live in this repo and our engineering team will be doing all our day to day work on Xaml on GitHub going forward. However the Microsoft.UI.Composition package that Xaml depends on will still be internally developed and only updated in binary form.

Thanks for the clarification @jesbis much appreciated. What distribution methods will you be using for this? We’re a cross-platform app, so using CMake, and have a dependency on Windows.UI.Composition, so would love a way of easily bringing in the new dll, lib, headers etc.

Are there any performance implications for extracting the Visual Layer from the OS? I.e. if you only depend on the Visual Layer, would there be a downside to updating to new library?

Is there a plan to eventually open source Microsoft.UI.Composition?

@MarkIngramUK I largely agree with what you are saying, and what @SavoySchuler is saying in a 'big-picture' view. As you pointed out though, it's harder for us WinUI 2.0 users to accept bugs as we have production apps right now. We need to find a compromise between fixing some bugs that won't delay WinUI 3.0 and also keeping WinUI 3.0 on track. There was an additional frustration that NumberBox was a brand new control that appeared to immediately be neglected -- with a comment that Microsoft wouldn't circle back to it for over a year. Regardless, I certainly agree WinUI 3.0 is the priority and wouldn't want it to be delayed in any significant capacity.

I probably should say I do appreciate all the work Microsoft is doing here and their efforts to be more transparent and communicative with direction.

What distribution methods will you be using for this? We’re a cross-platform app, so using CMake, and have a dependency on Windows.UI.Composition, so would love a way of easily bringing in the new dll, lib, headers etc.

@MarkIngramUK would consuming NuGet packages work for you? I.e. what we're doing with WinUI 2.x and the WinUI 3 Alpha. We're still working out some distribution details with the Visual Studio team. Right now the WinUI 3 Alpha contains both Xaml and Composition binaries in 1 package but we'll be separating them to support open sourcing Xaml and being able to build Xaml separately.

Are there any performance implications for extracting the Visual Layer from the OS? I.e. if you only depend on the Visual Layer, would there be a downside to updating to new library?

Stay tuned 🙂 Perf benchmarking and work is on our roadmap for later this year so it's a bit too early to have any numbers.

Is there a plan to eventually open source Microsoft.UI.Composition?

It's on our backlog to potentially consider but we don't have a plan for it.

@MarkIngramUK if I could ask: what benefit would you hope to get from it being open source?

Composition and rendering code can get a bit abstruse so I'm curious whether people would actually be interested in contributing or using as a reference.

it's harder for us WinUI 2.0 users to accept bugs as we have production apps right now. We need to find a compromise between fixing some bugs that won't delay WinUI 3.0 and also keeping WinUI 3.0 on track. There was an additional frustration that NumberBox was a brand new control that appeared to immediately be neglected -- with a comment that Microsoft wouldn't circle back to it for over a year. Regardless, I certainly agree WinUI 3.0 is the priority and wouldn't want it to be delayed in any significant capacity.
I probably should say I do appreciate all the work Microsoft is doing here and their efforts to be more transparent and communicative with direction.

@robloo thanks! We're really trying to be transparent and it's good to know that's valuable 🙂

Just to reiterate what Savoy mentioned we do have devs working on WinUI 2.x (as can hopefully be seen from the PR log too) so we're definitely still investing in both WinUI 2 and 3 in parallel - it's just that most of our resources are on WinUI 3. I agree about NumberBox in particular needing some attention and our Xaml controls dev lead is looking into it now.

@robloo You're the best! 😄 Sorry again for the confusion - the only thing that subject to that ~1 year delay mentioned was NumberBox's additional input validation modes because they are blocked on our all-up input validation work slated for 3.0. Otherwise @teaP, @ranjeshj, and I will be on the NumberBox bug list starting next week. 🙂

I think @jesbis got everything else covered!

@jesbis ,

@MarkIngramUK would consuming NuGet packages work for you? I.e. what we're doing with WinUI 2.x and the WinUI 3 Alpha. We're still working out some distribution details with the Visual Studio team. Right now the WinUI 3 Alpha contains both Xaml and Composition binaries in 1 package but we'll be separating them to support open sourcing Xaml and being able to build Xaml separately.

I'll be honest, I'm not that familiar with NuGet, but looking at this SO answer it seems it will only work if you use CMake to generate VS project files, which is not how we normally work (normally just open the folder, which uses Ninja as the generator). It's a shame you can't ship the source, as you could use vcpkg as well. For reference, we build all libraries from source (which avoids any potential ABI problems, especially given that we build with Clang/LLVM on Windows too).

Is there a plan to eventually open source Microsoft.UI.Composition?

It's on our backlog to potentially consider but we don't have a plan for it.

I have an interest in this, so I'd love to get involved in the discussion if / when that happens.

@MarkIngramUK if I could ask: what benefit would you hope to get from it being open source?

Composition and rendering code can get a bit abstruse so I'm curious whether people would actually be interested in contributing or using as a reference.

Initial thoughts are contributing / expanding (as I mentioned previously, we have a dependency on Windows.UI.Composition, but not the Xaml Framework / UWP), though thinking out loud, porting the Visual Layer to a Vulkan or Metal backend for cross-platform might be exciting, but I've only given that literally 30 seconds of consideration. Also, open sourcing would alleviate a nagging worry of adopting another framework that will eventually be abandoned by Microsoft in a few years time (our current apps are built on WPF, our previous apps were built on MFC, we had web components using Silverlight, so, you may see where I'm coming from here...).

NumberBox

Hi everyone! @teaP, @ranjeshj, and I worked through all our open NumberBox items today.

• We closed a few already.
• @teaP submitted a combined PR for several more (label filtering here).
• We have a course of action decided for the rest (with an exception of #1721) and will be responding with fixes ASAP. #1721 requires more work on our to diagnose the best path forward. We'll continue working to resolve this one.

Thank you to everyone for working with us. 🙂 We ❤️ WinUI!

Is there a "calendar" for the WinUI Community calls? Ex: in the form of a public calendar that we can add/integrate to our live/google/* calendar, for automatic updates of call details.

The YouTube events are scheduled ahead of time so you can add a Google reminder here under " upcoming live streams":

https://www.youtube.com/channel/UCzLbHrU7U3cUDNQWWAqjceA

We also had a .ics calendar invite but it was causing problems for some people and there was no way to update it so we gave up on that for now.