👨💻☎ WinUI Community Call - January 20, 2021

This call is now over, but you can watch the recording at the link below! This issue will be closed in a day or two, afterwards feel free to post any lingering questions as an issue on this repo or as a question for the next Community Call.
https://youtu.be/MulUg7iD2-s
Details
Date: Wednesday January 20, 2020
Time: 17:00-18: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 welcoming one of our community members!
Q&A: 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, background on WinUI - @anawishnoff
Community Spotlight - @niels9001 speaking on Fluent Design & WinUI
WPF Updates - @predavid-zz
WinUI 3 Schedule Updates - @ryandemopoulos
Q&A
Leave your questions below as well as general topics you'd like to hear about on the call!

Can you possibly detail how extensive the "Sun Valley" design refresh for Windows will be?

Will the UXTheme and MsStyles be updated?
Dark Mode for GDI apps?
Updated WPF Control Templates and support for Dark Mode?
Updates to FluentUI to match WinUI for PWA and WebView apps?\

oh and another confirmation Acrylic wont be too far away from 3.0's release (I always ask this question!)

Can you possibly detail how extensive the "Sun Valley" design refresh for Windows will be?

Will the UXTheme and MsStyles be updated?
Dark Mode for GDI apps?
Updated WPF Control Templates and support for Dark Mode?
Updates to FluentUI to match WinUI for PWA and WebView apps?\

oh and another confirmation Acrylic wont be too far away from 3.0's release (I always ask this question!)

It's 2021 now. What's the progress of open source?

It's 2021 now. What's the progress of open source?

Are the Fluent System Icon set on Figma planned to come to Windows soon?

Are the Fluent System Icon set on Figma planned to come to Windows soon?

When do we expect the open source, and when is the support for dotnet and UWP coming?

When do we expect the open source, and when is the support for dotnet and UWP coming?

Tell us more about the tooling.

Tell us more about the tooling.

It seems like Windows Ink has been largely ignored for years now. Is there any plan to bring some of the "rich inking" experience (like in Microsoft's apps like Whiteboard and OneNote) into WinUI?

It seems like Windows Ink has been largely ignored for years now. Is there any plan to bring some of the "rich inking" experience (like in Microsoft's apps like Whiteboard and OneNote) into WinUI?

I really want WinUI 3 to succeed, since it will bring many benefits for our app's users.
Unfortunately, I still can't get these features to work:

Use toast notification activations on desktop
Use protocol activations on desktop
Get WebAuthenticationBroker to work on desktop
Drag/drop (using custom bitmaps)
Open the app using an execution alias
Without these features, we can't migrate our UWP app to WinUI 3 Desktop.
Are these features on the roadmap?

I really want WinUI 3 to succeed, since it will bring many benefits for our app's users.
Unfortunately, I still can't get these features to work:

Use toast notification activations on desktop
Use protocol activations on desktop
Get WebAuthenticationBroker to work on desktop
Drag/drop (using custom bitmaps)
Open the app using an execution alias
Without these features, we can't migrate our UWP app to WinUI 3 Desktop.
Are these features on the roadmap?

I don't understand all the fuzz about open sourcing, fluent design, theming and other gold plating features when there are so many issues in getting LOB features to work on WinUI.

I don't understand all the fuzz about open sourcing, fluent design, theming and other gold plating features when there are so many issues in getting LOB features to work on WinUI.

Hello
For protocol activation it's independent of the UI framework. you can normally do this with the MSIX manifest and by calling the AppInstance.GetActivatedEventArgs static function.
I have already used it for file activation but I have not tested it for protocol activation. You can also take a look at the App Lifecycle Project Reunion issue on GitHub that aim to port the UWP App Lifecycle to desktop Apps
For the desktop app execution alias it's also already available in MSIX but be careful this doesn't use the CommandLineActivatedEventArgs but the LaunchActivatedEventArgs. So you can use the classical Win32 method to get the command line arguments.

Hello
For protocol activation it's independent of the UI framework. you can normally do this with the MSIX manifest and by calling the AppInstance.GetActivatedEventArgs static function.
I have already used it for file activation but I have not tested it for protocol activation. You can also take a look at the App Lifecycle Project Reunion issue on GitHub that aim to port the UWP App Lifecycle to desktop Apps
For the desktop app execution alias it's also already available in MSIX but be careful this doesn't use the CommandLineActivatedEventArgs but the LaunchActivatedEventArgs. So you can use the classical Win32 method to get the command line arguments.

I really want WinUI 3 to succeed, since it will bring many benefits for our app's users.
Unfortunately, I still can't get these features to work:

Use protocol activations on desktop
Get WebAuthenticationBroker to work on desktop
Drag/drop (using custom bitmaps)
Open the app using an execution alias
Without these features, we can't migrate our UWP app to WinUI 3 Desktop.
Are these features on the roadmap?

Hello
For protocol activation it's independent of the UI framework. you can normally do this with the MSIX manifest and by calling the AppInstance.GetActivatedEventArgs static function.
I have already used it for file activation but I have not tested it for protocol activation. You can also take a look at the App Lifecycle Project Reunion issue on GitHub that aim to port the UWP App Lifecycle to desktop Apps
For the desktop app execution alias it's also already available in MSIX but be careful this doesn't use the CommandLineActivatedEventArgs but the LaunchActivatedEventArgs. So you can use the classical Win32 method to get the command line arguments.

I really want WinUI 3 to succeed, since it will bring many benefits for our app's users.
Unfortunately, I still can't get these features to work:

Use protocol activations on desktop
Get WebAuthenticationBroker to work on desktop
Drag/drop (using custom bitmaps)
Open the app using an execution alias
Without these features, we can't migrate our UWP app to WinUI 3 Desktop.
Are these features on the roadmap?

Hello
For protocol activation it's independent of the UI framework. you can normally do this with the MSIX manifest and by calling the AppInstance.GetActivatedEventArgs static function.
I have already used it for file activation but I have not tested it for protocol activation. You can also take a look at the App Lifecycle Project Reunion issue on GitHub that aim to port the UWP App Lifecycle to desktop Apps
For the desktop app execution alias it's also already available in MSIX but be careful this doesn't use the CommandLineActivatedEventArgs but the LaunchActivatedEventArgs. So you can use the classical Win32 method to get the command line arguments.

I really want WinUI 3 to succeed, since it will bring many benefits for our app's users.
Unfortunately, I still can't get these features to work:

Use protocol activations on desktop
Get WebAuthenticationBroker to work on desktop
Drag/drop (using custom bitmaps)
Open the app using an execution alias
Without these features, we can't migrate our UWP app to WinUI 3 Desktop.
Are these features on the roadmap?

Hello @wbokkers
For protocol activation it's independent of the UI framework. you can normally do this with the MSIX manifest and by calling the AppInstance.GetActivatedEventArgs static function.
I have already used it for file activation but I have not tested it for protocol activation. You can also take a look at the App Lifecycle Project Reunion issue on GitHub that aim to port the UWP App Lifecycle to desktop Apps
For the desktop app execution alias it's also already available in MSIX but be careful this doesn't use the CommandLineActivatedEventArgs but the LaunchActivatedEventArgs. So you can use the classical Win32 method to get the command line arguments.

I really want WinUI 3 to succeed, since it will bring many benefits for our app's users.
Unfortunately, I still can't get these features to work:

Use protocol activations on desktop
Get WebAuthenticationBroker to work on desktop
Drag/drop (using custom bitmaps)
Open the app using an execution alias
Without these features, we can't migrate our UWP app to WinUI 3 Desktop.
Are these features on the roadmap?

Hello @wbokkers
For protocol activation it's independent of the UI framework. you can normally do this with the MSIX manifest and by calling the AppInstance.GetActivatedEventArgs static function.
I have already used it for file activation but I have not tested it for protocol activation. You can also take a look at the App Lifecycle Project Reunion issue on GitHub that aim to port the UWP App Lifecycle to desktop Apps
For the desktop app execution alias it's also already available in MSIX but be careful this doesn't use the CommandLineActivatedEventArgs but the LaunchActivatedEventArgs. So you can use the classical Win32 method to get the command line arguments.

I don't understand all the fuzz about open sourcing, fluent design, theming and other gold plating features when there are so many issues in getting LOB features to work on WinUI.

The idea is to decouple the WinUI framework from the OS version.  Once WinUI has been lifted out of the Windows codebase, then it allows them and the community to update, add features, fix bugs, and move the framework forward, rather than being tied to the twice yearly OS updates, and ensure new features be available for the other supported versions of Windows 10

I don't understand all the fuzz about open sourcing, fluent design, theming and other gold plating features when there are so many issues in getting LOB features to work on WinUI.

The idea is to decouple the WinUI framework from the OS version.  Once WinUI has been lifted out of the Windows codebase, then it allows them and the community to update, add features, fix bugs, and move the framework forward, rather than being tied to the twice yearly OS updates, and ensure new features be available for the other supported versions of Windows 10

@mveril Thank you, Mickaël. I couldn't get it to work using the MSIX manifest for desktop, but I'll look into it again.

@mveril Thank you, Mickaël. I couldn't get it to work using the MSIX manifest for desktop, but I'll look into it again.

I've mentioned that new members introduced in WinUI 2.5 (InfoBar, NavigationView.FooterMenuItems) not available in WinUI 3 Preview.
When will they be ported? When can we switch to WinUI 3 as default branch?

I've mentioned that new members introduced in WinUI 2.5 (InfoBar, NavigationView.FooterMenuItems) not available in WinUI 3 Preview.
When will they be ported? When can we switch to WinUI 3 as default branch?

@mveril Thank you, Mickaël. I couldn't get it to work using the MSIX manifest for desktop, but I'll look into it again.
See also this issue: https://github.com/microsoft/microsoft-ui-xaml/issues/3441

@wbokkers Sorry I have tested it this weekend and effectively it's not working for WinUI 3 desktop contrary to WPF

@mveril Thank you, Mickaël. I couldn't get it to work using the MSIX manifest for desktop, but I'll look into it again.
See also this issue: https://github.com/microsoft/microsoft-ui-xaml/issues/3441

@wbokkers Sorry I have tested it this weekend and effectively it's not working for WinUI 3 desktop contrary to WPF

Hello! I have three questions:

Will there be a WinUI Preview 4? If so, when?

Is there a fix for the DataGrid (Windows Community Toolkit) crashing when scrollbars are needed? If so, will it be in the Preview 4 or will there be a new Windows Community Toolkit release (preview or regular) that will have a fix?

Will there be a public release of Win2D (preview or regular) that supports WinUI 3 before the WinUI 3.0 release (either with WinUI Preview 4 or stand-alone)?

Hello! I have three questions:

Will there be a WinUI Preview 4? If so, when?

Is there a fix for the DataGrid (Windows Community Toolkit) crashing when scrollbars are needed? If so, will it be in the Preview 4 or will there be a new Windows Community Toolkit release (preview or regular) that will have a fix?

Will there be a public release of Win2D (preview or regular) that supports WinUI 3 before the WinUI 3.0 release (either with WinUI Preview 4 or stand-alone)?

Is it true that WinUI3 isn't going to work on Windows Insider builds until it goes GA? (source)

Is it true that WinUI3 isn't going to work on Windows Insider builds until it goes GA? (source)

I'm also curious if there will be a WinUI 3.0 Preview 4. If there is a Preview 4, will it have a 'go-live' moniker (no breaking changes)?
Can you get more specific yet about the WinUI 3.0 release date, or is it still 2021 H1? (Launching during Ignite or Build?)

My editors are hoping to sync up my book's release as close as possible with RTM.

I'm also curious if there will be a WinUI 3.0 Preview 4. If there is a Preview 4, will it have a 'go-live' moniker (no breaking changes)?
Can you get more specific yet about the WinUI 3.0 release date, or is it still 2021 H1? (Launching during Ignite or Build?)

My editors are hoping to sync up my book's release as close as possible with RTM.

At the moment the roadmap has a bunch of things listed as Post-3.0 (3.x releases)
https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md
Will we be getting the Roadmap updated with specific lists for 3.1 and 3.2 etc - and possible dates these releases will be aiming for?

At the moment the roadmap has a bunch of things listed as Post-3.0 (3.x releases)
https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md
Will we be getting the Roadmap updated with specific lists for 3.1 and 3.2 etc - and possible dates these releases will be aiming for?

will there be an update with the newer fluent icons for the "Segoe MDL2 Assets" font in windows?

will there be an update with the newer fluent icons for the "Segoe MDL2 Assets" font in windows?

There are still many reasons for WPF apps and sometimes it is the only choice due to technical constraints (controls ecosystem, embedding ActiveX, compat., running as Admin, etc.). When do we see some investments in WPF? Better, faster rendering, compiled bindings, etc.

There are still many reasons for WPF apps and sometimes it is the only choice due to technical constraints (controls ecosystem, embedding ActiveX, compat., running as Admin, etc.). When do we see some investments in WPF? Better, faster rendering, compiled bindings, etc.

@ranjeshj It would also be great to try out our apps with the new styles for controls (through preview releases of 2.6). This way we would be able to give any feedback we may have using it in real world apps.

@ranjeshj It would also be great to try out our apps with the new styles for controls (through preview releases of 2.6). This way we would be able to give any feedback we may have using it in real world apps.

@harvinders You can already test the news styles with this snippet:
<XamlControlsResources xmlns="using:Microsoft.UI.Xaml.Controls" Version="Latest"/>

Note that this API is still a WIP and might change.

@harvinders You can already test the news styles with this snippet:
<XamlControlsResources xmlns="using:Microsoft.UI.Xaml.Controls" Version="Latest"/>

Note that this API is still a WIP and might change.

What's the status of the wysiwyg editor for XAML (for winui3/c++) ?

What's the status of the wysiwyg editor for XAML (for winui3/c++) ?

Tell us more about the tooling. And be open to provide answers to people - even if it means shipping the features next year.

@saint4eva, do you have more specifics? I just want to make sure we actually answer your question, because I could probably say a lot about this :)

Tell us more about the tooling. And be open to provide answers to people - even if it means shipping the features next year.

@saint4eva, do you have more specifics? I just want to make sure we actually answer your question, because I could probably say a lot about this :)

I've noticed some PRs in the microsoft-ui-xaml repo which make significantly large changes to common controls such as buttons and sliders. What's the goal of these changes, and is there a roadmap?

I've noticed some PRs in the microsoft-ui-xaml repo which make significantly large changes to common controls such as buttons and sliders. What's the goal of these changes, and is there a roadmap?

Is there a plan to update UXTheme styles to match WinUI controls on windows?

Is there a plan to update UXTheme styles to match WinUI controls on windows?

For future calls: as you record via MSTeams, please can you enable live captioning to help those of us who have difficulty hearing

For future calls: as you record via MSTeams, please can you enable live captioning to help those of us who have difficulty hearing

@mrlacey - That's an excellent suggestion, thank you! I'll look into that for the next call.

@mrlacey - That's an excellent suggestion, thank you! I'll look into that for the next call.

First, I'd like to qualify the following remarks as a personal view only, I don't pretend to speak for the wider WPF or UWP dev community.  I still find the communications associated with WinUI bewildering.  Community calls seem to be devolving.
The messaging around WinUI needs to change dramatically; because WinUI timelines have become opaque; because the premise of WinUI has become even more opaque; because the work being done on WinUI is being done behind a curtain (so much for all the Open Source bravado); because deliverables keep getting whittled down to a feature set that is deficient for a minimally viable alternative to what WPF and UWP both offer today.
A version 0.5 product designation, if we're going to be honest is really an alpha stage release that has all the bugs stripped out.  Giving the October 1.0 release a 1.0 designation isn't honest either since it will be missing significant capabilities relative to present day features of WPF and UWP and is not likely to be as stable or as performant as UWP is today.
Remarks about client side development being defunded by Microsoft don't help either.
Hard questions seldom get answered, beyond a "we'll get back to you."
What's also mystifying is the premise that Microsoft is listening to its customers.  Apparently lots of folks were clamoring for XAML Islands to ease modernization efforts, yet this capability will be missing from WPF .Net 5 "by design"?  I sincerely doubt any WPF devs will pick .Net Core 3.1 over .Net 5 as their preferred path forward, and will bypass using XAML Islands altogether.  Especially given options like: https://github.com/Kinnara/ModernWpf
None of the developers I know that use WPF (myself included) are moving their large apps to UWP simply because it is still missing critical LOB capabilities that make the port too painful to consider.  Only fresh start efforts might get such a consideration (to which corp managers say no as we've seen with current UWP adoption rates).  Hence, WinUI is unlikely to entice WPF developers to adopt a UWP dev paradigm despite the sandbox free execution context.  XAML Islands was supposed to be the baby step path forward to modernization.  Yet that path is now a dead end with .Net Core 3.x.
Microsoft could have ported Winforms and WPF so they ran on top of the UWP compositor and given WPF/Winforms/UWP an unrestricted execution mode in addition to a sandboxed execution context.  WPF and Winforms would be way faster running on top of UWP's compositor.  Yes, that leaves out the MFC/C++ devs.  With better tooling and OS support, C++ UWP could have been a viable option for MFC/C++.
The WinRT API was initially sold as the great new thing and the future of Windows.  What happened?
It's ok to say WinUI will be available in 2022 provided the wheels on UWP and WPF keep getting lubed.  At the moment, it looks like WinUI is taking all the oxygen away from the world we, your loyal developer community, live in.
Please don't tell us React Native is the new way forward unless you wish to accelerate retirement plans for XAML diehards.  I'd rather be lied to.

First, I'd like to qualify the following remarks as a personal view only, I don't pretend to speak for the wider WPF or UWP dev community.  I still find the communications associated with WinUI bewildering.  Community calls seem to be devolving.
The messaging around WinUI needs to change dramatically; because WinUI timelines have become opaque; because the premise of WinUI has become even more opaque; because the work being done on WinUI is being done behind a curtain (so much for all the Open Source bravado); because deliverables keep getting whittled down to a feature set that is deficient for a minimally viable alternative to what WPF and UWP both offer today.
A version 0.5 product designation, if we're going to be honest is really an alpha stage release that has all the bugs stripped out.  Giving the October 1.0 release a 1.0 designation isn't honest either since it will be missing significant capabilities relative to present day features of WPF and UWP and is not likely to be as stable or as performant as UWP is today.
Remarks about client side development being defunded by Microsoft don't help either.
Hard questions seldom get answered, beyond a "we'll get back to you."
What's also mystifying is the premise that Microsoft is listening to its customers.  Apparently lots of folks were clamoring for XAML Islands to ease modernization efforts, yet this capability will be missing from WPF .Net 5 "by design"?  I sincerely doubt any WPF devs will pick .Net Core 3.1 over .Net 5 as their preferred path forward, and will bypass using XAML Islands altogether.  Especially given options like: https://github.com/Kinnara/ModernWpf
None of the developers I know that use WPF (myself included) are moving their large apps to UWP simply because it is still missing critical LOB capabilities that make the port too painful to consider.  Only fresh start efforts might get such a consideration (to which corp managers say no as we've seen with current UWP adoption rates).  Hence, WinUI is unlikely to entice WPF developers to adopt a UWP dev paradigm despite the sandbox free execution context.  XAML Islands was supposed to be the baby step path forward to modernization.  Yet that path is now a dead end with .Net Core 3.x.
Microsoft could have ported Winforms and WPF so they ran on top of the UWP compositor and given WPF/Winforms/UWP an unrestricted execution mode in addition to a sandboxed execution context.  WPF and Winforms would be way faster running on top of UWP's compositor.  Yes, that leaves out the MFC/C++ devs.  With better tooling and OS support, C++ UWP could have been a viable option for MFC/C++.
The WinRT API was initially sold as the great new thing and the future of Windows.  What happened?
It's ok to say WinUI will be available in 2022 provided the wheels on UWP and WPF keep getting lubed.  At the moment, it looks like WinUI is taking all the oxygen away from the world we, your loyal developer community, live in.
Please don't tell us React Native is the new way forward unless you wish to accelerate retirement plans for XAML diehards.  I'd rather be lied to.

Thanking for asking my both questions. I'll do some explanation about them.
Currently I'm unsatisfied with the preview experience:

There are several critical bugs living for several prereleases, like the nested NavigationView one. Some of them prevents a feature to be used totally.
The intervals between previews are long. We have to wait for the bug fix. And if it's not fixed in one preview, we have to wait for another several months.
Since it's not open sourced, we cannot see the progress of bug fixing, nor compiling directly from master to get critical fix.

You have many works and can't change your workflow. Please be more active on GitHub with the issues. Make a comment for you are investigating, getting fixed in internal preview, or even investigated but feels too complex. Let us know more about progress of fixing bugs recorded on GitHub.

Thanking for asking my both questions. I'll do some explanation about them.
Currently I'm unsatisfied with the preview experience:

There are several critical bugs living for several prereleases, like the nested NavigationView one. Some of them prevents a feature to be used totally.
The intervals between previews are long. We have to wait for the bug fix. And if it's not fixed in one preview, we have to wait for another several months.
Since it's not open sourced, we cannot see the progress of bug fixing, nor compiling directly from master to get critical fix.

You have many works and can't change your workflow. Please be more active on GitHub with the issues. Make a comment for you are investigating, getting fixed in internal preview, or even investigated but feels too complex. Let us know more about progress of fixing bugs recorded on GitHub.

Is "Multi-window support for Desktop apps" included in March release coming with Project Reunion 0.5?

Is "Multi-window support for Desktop apps" included in March release coming with Project Reunion 0.5?

Some people mentioned here bugs, that, maybe, will be fixed next preview version, but some developers, who loves testing new features, including myself, are stopped with current preview 3 and insider builds on without any option to develop again their apps, because of some bug in Windows insider versions. No workaround, no further information, just message, we must wait to next release, which will be in March. It needed two issues to be reported we get some response  (#3815 and #3954). Many people believe(d) WinUI 3 will bring new options of developing, new possibilities, modern UI and many more things, but it still looks like some alpha version. Another problem was with content dialog. The first thing, that I tried on WinUI 3. In just few days I found 2 bugs, which one of it was critical so it was unable to use this control (#3804). Funny is, terminal team found this bug and only workaround was: Don't use it, we don't do it neither.
I could work without xaml designer, i could work without some functions and controls, but this isn't just controls, this is much more wider problem.

Some people mentioned here bugs, that, maybe, will be fixed next preview version, but some developers, who loves testing new features, including myself, are stopped with current preview 3 and insider builds on without any option to develop again their apps, because of some bug in Windows insider versions. No workaround, no further information, just message, we must wait to next release, which will be in March. It needed two issues to be reported we get some response  (#3815 and #3954). Many people believe(d) WinUI 3 will bring new options of developing, new possibilities, modern UI and many more things, but it still looks like some alpha version. Another problem was with content dialog. The first thing, that I tried on WinUI 3. In just few days I found 2 bugs, which one of it was critical so it was unable to use this control (#3804). Funny is, terminal team found this bug and only workaround was: Don't use it, we don't do it neither.
I could work without xaml designer, i could work without some functions and controls, but this isn't just controls, this is much more wider problem.

Some people mentioned here bugs, that, maybe, will be fixed next preview version, but some developers, who loves testing new features, including myself, are stopped with current preview 3 and insider builds on without any option to develop again their apps, because of some bug in Windows insider versions. No workaround, no further information, just message, we must wait to next release, which will be in March. It needed two issues to be reported we get some response (#3815 and #3954). Many people believe(d) WinUI 3 will bring new options of developing, new possibilities, modern UI and many more things, but it still looks like some alpha version. Another problem was with content dialog. The first thing, that I tried on WinUI 3. In just few days I found 2 bugs, which one of it was critical so it was unable to use this control (#3804). Funny is, terminal team found this bug and only workaround was: Don't use it, we don't do it neither.
I could work without xaml designer, i could work without some functions and controls, but this isn't just controls, this is much more wider problem.

Have to agree with this, coming from Swift when Apple make a development decision and do pre-releases, we're in a position to not just build MVP's but know that in 12 months it can be production ready and released to market.
I was at WWDC when Apple announced Swift, there were grumbles after the announcement, but everyone knew on that day that Swift was the future and everyone had their hands on the latest macOS and iOS releases to get their hands dirty. I don't have that same confidence with WinUI 3. That's just my opinion, and may be jaded by not knowing what to build my apps in right now, i.e. UWP, WPF, WinUI or just roll with the punches in Flutter, Electron or React Native for Desktop.
I don't want to dishearten anyone on the team, I know a lot goes into this work, I'm on insiders dev channel so obviously haven't had the opportunity to experience it.
For people just getting into Windows development it can be off putting and disheartening when they go through the effort of installing everything and can't even get their app to run and their only option is to wait several months or re-image their machine. Even now the documentation hasn't been updated to let people know that it won't run on insider previews.

Some people mentioned here bugs, that, maybe, will be fixed next preview version, but some developers, who loves testing new features, including myself, are stopped with current preview 3 and insider builds on without any option to develop again their apps, because of some bug in Windows insider versions. No workaround, no further information, just message, we must wait to next release, which will be in March. It needed two issues to be reported we get some response (#3815 and #3954). Many people believe(d) WinUI 3 will bring new options of developing, new possibilities, modern UI and many more things, but it still looks like some alpha version. Another problem was with content dialog. The first thing, that I tried on WinUI 3. In just few days I found 2 bugs, which one of it was critical so it was unable to use this control (#3804). Funny is, terminal team found this bug and only workaround was: Don't use it, we don't do it neither.
I could work without xaml designer, i could work without some functions and controls, but this isn't just controls, this is much more wider problem.

Have to agree with this, coming from Swift when Apple make a development decision and do pre-releases, we're in a position to not just build MVP's but know that in 12 months it can be production ready and released to market.
I was at WWDC when Apple announced Swift, there were grumbles after the announcement, but everyone knew on that day that Swift was the future and everyone had their hands on the latest macOS and iOS releases to get their hands dirty. I don't have that same confidence with WinUI 3. That's just my opinion, and may be jaded by not knowing what to build my apps in right now, i.e. UWP, WPF, WinUI or just roll with the punches in Flutter, Electron or React Native for Desktop.
I don't want to dishearten anyone on the team, I know a lot goes into this work, I'm on insiders dev channel so obviously haven't had the opportunity to experience it.
For people just getting into Windows development it can be off putting and disheartening when they go through the effort of installing everything and can't even get their app to run and their only option is to wait several months or re-image their machine. Even now the documentation hasn't been updated to let people know that it won't run on insider previews.

I remember days, when was Windows 8 introduced and Microsoft had great plans to merge mobile and desktop platforms together. OneNote for Windows 8 was great app with, in my opinion, revolution radial context menu. MS has great concepts, great plans, but sometimes many of them fail, because ... it is hard to make it real? i don't know, but progress last years is extremely slow to compare to effort on Android. Launcher, keyboard, all other apps. I hope one day I will see same effort in desktop. Many people are hyped for Sun Valley, because it could bring this hope to reality and make Windows modern and user friendly. Yeah, phones are bigger and bigger part of our lives, but desktop won't disappear, because of phones. I use Windows 16 hours per day, maybe more. I use it in work, at home, in bed during learning for exams, for presentations, for everything in my life. I always my phone nearby, but many times i sent links to PC, continue on PC, because it is better. Bigger screen, bigger keyboard, much bigger performance, multiple screens.
People in MS are doing great work, no doubt, but I see it work many times in other parts of main products and technologies, like WPF, UWP and so on. I made framework for quick creating information systems based on modules. All in UWP, it works and with some touches could be used for production apps, but future of UWP is uncertain. Everything is PWA, but performance is there horrible and UX same.
Why wasn't UWP brought to perfection as WPF? Why UWP miss many capabilities compare to WPF? But okay, move on. Now we have here WinUI 3. Something, what i see as combination of both. For my master thesis I select Win UI 3 as option to create great modern apps with capabilities, which developers know. New UI based on Fluent, that from day, when was it introduced as Project Neon, I saw as new modern wind to windows. Many apps still don't fully implement it and if so, it still has specific UI differences.
MS now has great opportunity to show, they know how to do great apps, great OS and great tools for developers, who could use it in their apps, and their own system is something, want they want to do. Many people, and not just developers, but users too, expecting you bring this year something unbelievable to us. And with WinUI 3 we could participate in it too. Many developers are waiting and want to help you to shape it to perfection. Together we could make it available to all and make many people happy again from using Windows.

I remember days, when was Windows 8 introduced and Microsoft had great plans to merge mobile and desktop platforms together. OneNote for Windows 8 was great app with, in my opinion, revolution radial context menu. MS has great concepts, great plans, but sometimes many of them fail, because ... it is hard to make it real? i don't know, but progress last years is extremely slow to compare to effort on Android. Launcher, keyboard, all other apps. I hope one day I will see same effort in desktop. Many people are hyped for Sun Valley, because it could bring this hope to reality and make Windows modern and user friendly. Yeah, phones are bigger and bigger part of our lives, but desktop won't disappear, because of phones. I use Windows 16 hours per day, maybe more. I use it in work, at home, in bed during learning for exams, for presentations, for everything in my life. I always my phone nearby, but many times i sent links to PC, continue on PC, because it is better. Bigger screen, bigger keyboard, much bigger performance, multiple screens.
People in MS are doing great work, no doubt, but I see it work many times in other parts of main products and technologies, like WPF, UWP and so on. I made framework for quick creating information systems based on modules. All in UWP, it works and with some touches could be used for production apps, but future of UWP is uncertain. Everything is PWA, but performance is there horrible and UX same.
Why wasn't UWP brought to perfection as WPF? Why UWP miss many capabilities compare to WPF? But okay, move on. Now we have here WinUI 3. Something, what i see as combination of both. For my master thesis I select Win UI 3 as option to create great modern apps with capabilities, which developers know. New UI based on Fluent, that from day, when was it introduced as Project Neon, I saw as new modern wind to windows. Many apps still don't fully implement it and if so, it still has specific UI differences.
MS now has great opportunity to show, they know how to do great apps, great OS and great tools for developers, who could use it in their apps, and their own system is something, want they want to do. Many people, and not just developers, but users too, expecting you bring this year something unbelievable to us. And with WinUI 3 we could participate in it too. Many developers are waiting and want to help you to shape it to perfection. Together we could make it available to all and make many people happy again from using Windows.

We've read a lot of thoughts, suggestions, and opinions here. And we are grateful for all of them, even the criticism, because we can learn from them and serve you better. Sometimes we have the time to respond to the community, others we don't have the bandwidth to give you a proper answer on time, my more sincerest apologies for that. Please, continue giving us your feedback; there is always room for improvement.
Luckily, the good news is that we are already addressing some feedback, but it requires some steps first before being there.
Answering some questions:

Is "Multi-window support for Desktop apps" included in March release coming with Project Reunion 0.5?

The March release will include Multi-window support in Desktop WinUI 3 apps. However,  it will allow only one Window per thread. We won't support multi-window on the same thread because we are not happy with the current quality of the bits. I demo'ed it several times in some public events, but we found several scenarios where the current implementation is not reliable. So we have postponed it.

WinUI3 apps not running on Windows Insider build 21292.1000

The team is trying to support the Windows Insiders' latest bits, but it is not always possible. Remember, we need to support the older versions of Windows, and the matrix of testability is enormous, as the cost of maintenance. So we decided to prioritize final releases of Windows first (given they are the ones that will be in the production environment), and then the rest. Windows Insider bugs are lower than Windows Releases in our ranking list.

Please ship preleases much more frequently. The quality of Preview 3 is still far from GA. There must be a Preview 4.

We want to do it, and we are planning to do it. This is one of those things that will be accelerated when we made WinUI 3 open source. But even without being open source, the new release cycles, with previews and supported versions, should help give you bits more frequently.

ContentDialog Input not working for TextBox

Ugly bug. This is the type of bug that looks simple, but it is complicated to fix. Fortunately, I believe it has been fixed in the main branch, so it should be part of the March release.

We've read a lot of thoughts, suggestions, and opinions here. And we are grateful for all of them, even the criticism, because we can learn from them and serve you better. Sometimes we have the time to respond to the community, others we don't have the bandwidth to give you a proper answer on time, my more sincerest apologies for that. Please, continue giving us your feedback; there is always room for improvement.
Luckily, the good news is that we are already addressing some feedback, but it requires some steps first before being there.
Answering some questions:

Is "Multi-window support for Desktop apps" included in March release coming with Project Reunion 0.5?

The March release will include Multi-window support in Desktop WinUI 3 apps. However,  it will allow only one Window per thread. We won't support multi-window on the same thread because we are not happy with the current quality of the bits. I demo'ed it several times in some public events, but we found several scenarios where the current implementation is not reliable. So we have postponed it.

WinUI3 apps not running on Windows Insider build 21292.1000

The team is trying to support the Windows Insiders' latest bits, but it is not always possible. Remember, we need to support the older versions of Windows, and the matrix of testability is enormous, as the cost of maintenance. So we decided to prioritize final releases of Windows first (given they are the ones that will be in the production environment), and then the rest. Windows Insider bugs are lower than Windows Releases in our ranking list.

Please ship preleases much more frequently. The quality of Preview 3 is still far from GA. There must be a Preview 4.

We want to do it, and we are planning to do it. This is one of those things that will be accelerated when we made WinUI 3 open source. But even without being open source, the new release cycles, with previews and supported versions, should help give you bits more frequently.

ContentDialog Input not working for TextBox

Ugly bug. This is the type of bug that looks simple, but it is complicated to fix. Fortunately, I believe it has been fixed in the main branch, so it should be part of the March release.

@marb2000 Thank you Miguel for providing answers to some of the questions in a more sincere and open-manner - we appreciate it. One more question, please could throw more light on the state of UWP app model on WinUI and the status of the .NET support for UWP/ WinUI.
Thank you in advance.

@marb2000 Thank you Miguel for providing answers to some of the questions in a more sincere and open-manner - we appreciate it. One more question, please could throw more light on the state of UWP app model on WinUI and the status of the .NET support for UWP/ WinUI.
Thank you in advance.

Sometimes we have the time to respond to the community, others we don't have the bandwidth to give you a proper answer on time, my more sincerest apologies for that.

We know you can't always give a quick answer to every question but this response could easily be interpreted as implying "we're to busy to engage with the community." For a project that wants lots of community engagement and intends to eventually be fully open-source, this doesn't send a good message.
Also supporting the need for more communication is that (from my perspective) a lot of questions that are being asked (on this thread and the wider repo) are about clarification or due to a lack of information. For example, on the call 3 days ago, we were told the roadmap has changed and new dates added. But the documentation has still not been updated.
Similarly, you acknowledge that there are issues with using Preview3 on the latest Windows Insider Preview builds but the homepage explicitly calls out that Windows Insider Previews are supported. At best it's not clear that that message only applies to 2.*? Is this another example of where you (collectively--I'm not picking on an individual) don't have the time to keep the community informed or up to date?

Sometimes we have the time to respond to the community, others we don't have the bandwidth to give you a proper answer on time, my more sincerest apologies for that.

We know you can't always give a quick answer to every question but this response could easily be interpreted as implying "we're to busy to engage with the community." For a project that wants lots of community engagement and intends to eventually be fully open-source, this doesn't send a good message.
Also supporting the need for more communication is that (from my perspective) a lot of questions that are being asked (on this thread and the wider repo) are about clarification or due to a lack of information. For example, on the call 3 days ago, we were told the roadmap has changed and new dates added. But the documentation has still not been updated.
Similarly, you acknowledge that there are issues with using Preview3 on the latest Windows Insider Preview builds but the homepage explicitly calls out that Windows Insider Previews are supported. At best it's not clear that that message only applies to 2.*? Is this another example of where you (collectively--I'm not picking on an individual) don't have the time to keep the community informed or up to date?

It's better to release a huge RTM than a half baked or a stable, feature incomplete WinUI3.0 that doesn't have feature parity with WinUI2.5.
Microsoft releasing unfinished products is a main complaint about Microsoft from people in general. People keep complaining about it but Microsoft keeps doing it and wonder why people aren't using the products and cancels them.
https://answers.microsoft.com/en-us/windows/forum/all/why-does-microsoft-get-to-release-an-unfinished/fe660b84-19f5-467b-8eca-e9fb297e123c

It's better to release a huge RTM than a half baked or a stable, feature incomplete WinUI3.0 that doesn't have feature parity with WinUI2.5.
Microsoft releasing unfinished products is a main complaint about Microsoft from people in general. People keep complaining about it but Microsoft keeps doing it and wonder why people aren't using the products and cancels them.
https://answers.microsoft.com/en-us/windows/forum/all/why-does-microsoft-get-to-release-an-unfinished/fe660b84-19f5-467b-8eca-e9fb297e123c

I appreciate the many questions here.  Beyond what Miguel wrote, allow me to address what’s been asked so far—and as always I’ll aim to be as transparent as possible:

Will there be a WinUI Preview 4? If so, when?

@eleanorleffler @mrlacey @huoyaoyuan  @JanRajnoha  Yes, we are planning to ship a Preview 4 in early-mid Feb.  We decided to do this after last week’s Community Call, which is why I didn’t mentioned it on the call.  There’s three motivators for doing this:  1) Fix the issue where we don’t work on Insider Builds, and 2) start getting into a cadence of shipping Previews faster and more frequently, and 3) Get one more preview in before we ship our first supported release (another opportunity to gain feedback on bugs, things unstable, etc)

Is there a fix for the DataGrid (Windows Community Toolkit) crashing when scrollbars are needed?

@eleanorleffler We're still trying to reproduce this fix on our end; haven't been successful yet but we're exploring it.

Will there be a public release of Win2D (preview or regular) that supports WinUI 3 before the WinUI 3.0 release (either with WinUI Preview 4 or stand-alone)?

@eleanorleffler This is in active discussion internally; I don't have an answer yet but probably will have one soon.

Can you get more specific yet about the WinUI 3.0 release date, or is it still 2021 H1?
WinUI timelines have become opaque

@alvinashcraft @noemata There are 3 planned “supported” releases of WinUI 3 this year: one in March, one in May/June, and one in October.  Our WinUI roadmap document is in the process of being updated, so I apologize that update isn’t out yet—I suspect it’ll be a few days and when we’ll merge the update.  It should give you a reasonable sense of how various features are trending for each of those releases.
Additionally, as I mentioned on the call, we’re also changing how we ship.  We’ll be moving to a dual-channel ship cycle, similar to how WinUI 2 works, where we ship a “stable” set of features and a “preview” set (which include everything we’ve done).

A version 0.5 product designation, if we're going to be honest is really an alpha stage release that has all the bugs stripped out. Giving the October 1.0 release a 1.0 designation isn't honest either since it will be missing significant capabilities relative to present day features of WPF and UWP and is not likely to be as stable or as performant as UWP is today.

@noemata Being very transparent: many times I have pondered whether the name “WinUI 3” was the right name for what we work on.  We picked that name because it elevates most of the features of WinUI 2 and carries them forward into a new framework, so “WinUI 3” felt very natural as a name.  As well, WinUI 3 is intended to replace the WinUI 2 stack eventually, yet another reason why WinUI 3 seemed like the obviously correct name.
However, I do think this name has created some confusion where people think that WinUI 3 is going to be the successor to WinUI 2 the day that it first ships—and that isn’t the case.  There will be a period of time—probably a year or two—where WinUI 2 and WinUI 3 will both be state of the art, and developed in parallel.  The March, May, October, and even beyond October releases will be missing capabilities that WPF and UWP have; in some cases WinUI 3 might never bring some of those capabilities forward.  It is a new framework—it will have a steadily increasing set of similarities to those technologies that broaden over time, but it is also something different that will grow in its own unique direction.  We don’t want to wait on using 1.0-style terminology until it has all the capabilities of WinUI 2, because it’s not a goal for it to have all the capabilities of WinUI 2.  I hope that helps clear things up.
Regarding the 0.5 release: it is to be stable and free of most/all major bugs in the features that are included.  It won’t be an “Alpha”, or a “Beta”, or even a “Preview” in terms of stability—we’re intending it to be fully supported and something that people can start building & shipping real world apps on.  We’re following Semver2 versioning rules, and we anticipate there could be breaking changes between some of the earlier supported versions we ship (0.5, 0.8, 1.0), so that’s one of the main reasons why we’re starting off with 0.x numbering.

What's also mystifying is the premise that Microsoft is listening to its customers. Apparently lots of folks were clamoring for XAML Islands to ease modernization efforts, yet this capability will be missing from WPF .Net 5 "by design"?

@noemata It’s possible someone misspoke here, or perhaps is just using imprecise language—perhaps what they were talking about was XAML Islands in UWP XAML, rather than WinUI 3…?  To try and be clear: I’m hopeful to have XAML Islands done by our stable Oct release—we’re still evaluating our dev plans to see if that’s possible, but I think there’s a good chance Islands will land in October.  When Islands ships, it will work with the latest .NET (which would be .NET 5 in Oct, and .NET 6 after that).  I do apologize if it appears that we’re not listening to customers; the irony is that Islands still requires quite a lot of work (both in runtime and tooling), and was on a path for 2022 at one point, but the chorus of voices asking for us to ship it faster made us re-evaluate and that's why we're seeing if we can get it done this year.

Microsoft could have ported WinForms and WPF so they ran on top of the UWP compositor and given WPF/Winforms/UWP an unrestricted execution mode in addition to a sandboxed execution context.

@noemata WPF lacks many things; a modern compositor is only one of them.  If WPF works great for you, then please use it—it’s not a goal of anyone on the WinUI team to convince people that WPF should not be used; it’s solid technology that is more than good enough for many people.  WinUI 3 aims to be different: it will be a next-generation UX framework that we build next-generation UX experiences on for Windows.  Starting with WPF or WinForms would not achieve that goal.

Please don't tell us React Native is the new way forward unless you wish to accelerate retirement plans for XAML diehards

@noemata React Native is not the way forward since our platform strategy is to embrace several technologies, allowing developers to choose the technology that best suits their needs.  React Native is great for developers that want to write apps that look & feel native, but use JavaScript/JSX as the primary way to do it.  Traditional XAML developers will likely shy away from this—and that’s fine.  XAML developers continue to have other great options spanning WPF, WinUI 2, and soon WinUI 3 will be added to that mix.

Since it's not open sourced, we cannot see the progress of bug fixing, nor compiling directly from master to get critical fix

@huoyaoyuan You’re absolutely right.  As soon as we can be open source, we will be.  I don’t have a specific date and I wish I did; I will say that it remains an important aspiration for the team.
I do hope that helps—follow-up questions/dialog welcome.

I appreciate the many questions here.  Beyond what Miguel wrote, allow me to address what’s been asked so far—and as always I’ll aim to be as transparent as possible:

Will there be a WinUI Preview 4? If so, when?

@eleanorleffler @mrlacey @huoyaoyuan  @JanRajnoha  Yes, we are planning to ship a Preview 4 in early-mid Feb.  We decided to do this after last week’s Community Call, which is why I didn’t mentioned it on the call.  There’s three motivators for doing this:  1) Fix the issue where we don’t work on Insider Builds, and 2) start getting into a cadence of shipping Previews faster and more frequently, and 3) Get one more preview in before we ship our first supported release (another opportunity to gain feedback on bugs, things unstable, etc)

Is there a fix for the DataGrid (Windows Community Toolkit) crashing when scrollbars are needed?

@eleanorleffler We're still trying to reproduce this fix on our end; haven't been successful yet but we're exploring it.

Will there be a public release of Win2D (preview or regular) that supports WinUI 3 before the WinUI 3.0 release (either with WinUI Preview 4 or stand-alone)?

@eleanorleffler This is in active discussion internally; I don't have an answer yet but probably will have one soon.

Can you get more specific yet about the WinUI 3.0 release date, or is it still 2021 H1?
WinUI timelines have become opaque

@alvinashcraft @noemata There are 3 planned “supported” releases of WinUI 3 this year: one in March, one in May/June, and one in October.  Our WinUI roadmap document is in the process of being updated, so I apologize that update isn’t out yet—I suspect it’ll be a few days and when we’ll merge the update.  It should give you a reasonable sense of how various features are trending for each of those releases.
Additionally, as I mentioned on the call, we’re also changing how we ship.  We’ll be moving to a dual-channel ship cycle, similar to how WinUI 2 works, where we ship a “stable” set of features and a “preview” set (which include everything we’ve done).

A version 0.5 product designation, if we're going to be honest is really an alpha stage release that has all the bugs stripped out. Giving the October 1.0 release a 1.0 designation isn't honest either since it will be missing significant capabilities relative to present day features of WPF and UWP and is not likely to be as stable or as performant as UWP is today.

@noemata Being very transparent: many times I have pondered whether the name “WinUI 3” was the right name for what we work on.  We picked that name because it elevates most of the features of WinUI 2 and carries them forward into a new framework, so “WinUI 3” felt very natural as a name.  As well, WinUI 3 is intended to replace the WinUI 2 stack eventually, yet another reason why WinUI 3 seemed like the obviously correct name.
However, I do think this name has created some confusion where people think that WinUI 3 is going to be the successor to WinUI 2 the day that it first ships—and that isn’t the case.  There will be a period of time—probably a year or two—where WinUI 2 and WinUI 3 will both be state of the art, and developed in parallel.  The March, May, October, and even beyond October releases will be missing capabilities that WPF and UWP have; in some cases WinUI 3 might never bring some of those capabilities forward.  It is a new framework—it will have a steadily increasing set of similarities to those technologies that broaden over time, but it is also something different that will grow in its own unique direction.  We don’t want to wait on using 1.0-style terminology until it has all the capabilities of WinUI 2, because it’s not a goal for it to have all the capabilities of WinUI 2.  I hope that helps clear things up.
Regarding the 0.5 release: it is to be stable and free of most/all major bugs in the features that are included.  It won’t be an “Alpha”, or a “Beta”, or even a “Preview” in terms of stability—we’re intending it to be fully supported and something that people can start building & shipping real world apps on.  We’re following Semver2 versioning rules, and we anticipate there could be breaking changes between some of the earlier supported versions we ship (0.5, 0.8, 1.0), so that’s one of the main reasons why we’re starting off with 0.x numbering.

What's also mystifying is the premise that Microsoft is listening to its customers. Apparently lots of folks were clamoring for XAML Islands to ease modernization efforts, yet this capability will be missing from WPF .Net 5 "by design"?

@noemata It’s possible someone misspoke here, or perhaps is just using imprecise language—perhaps what they were talking about was XAML Islands in UWP XAML, rather than WinUI 3…?  To try and be clear: I’m hopeful to have XAML Islands done by our stable Oct release—we’re still evaluating our dev plans to see if that’s possible, but I think there’s a good chance Islands will land in October.  When Islands ships, it will work with the latest .NET (which would be .NET 5 in Oct, and .NET 6 after that).  I do apologize if it appears that we’re not listening to customers; the irony is that Islands still requires quite a lot of work (both in runtime and tooling), and was on a path for 2022 at one point, but the chorus of voices asking for us to ship it faster made us re-evaluate and that's why we're seeing if we can get it done this year.

Microsoft could have ported WinForms and WPF so they ran on top of the UWP compositor and given WPF/Winforms/UWP an unrestricted execution mode in addition to a sandboxed execution context.

@noemata WPF lacks many things; a modern compositor is only one of them.  If WPF works great for you, then please use it—it’s not a goal of anyone on the WinUI team to convince people that WPF should not be used; it’s solid technology that is more than good enough for many people.  WinUI 3 aims to be different: it will be a next-generation UX framework that we build next-generation UX experiences on for Windows.  Starting with WPF or WinForms would not achieve that goal.

Please don't tell us React Native is the new way forward unless you wish to accelerate retirement plans for XAML diehards

@noemata React Native is not the way forward since our platform strategy is to embrace several technologies, allowing developers to choose the technology that best suits their needs.  React Native is great for developers that want to write apps that look & feel native, but use JavaScript/JSX as the primary way to do it.  Traditional XAML developers will likely shy away from this—and that’s fine.  XAML developers continue to have other great options spanning WPF, WinUI 2, and soon WinUI 3 will be added to that mix.

Since it's not open sourced, we cannot see the progress of bug fixing, nor compiling directly from master to get critical fix

@huoyaoyuan You’re absolutely right.  As soon as we can be open source, we will be.  I don’t have a specific date and I wish I did; I will say that it remains an important aspiration for the team.
I do hope that helps—follow-up questions/dialog welcome.

@ryandemopoulos , your remarks, more than any others give me a little piece of mind.  In particular your "probably a year or two" remark about of parallel UWP/WinUI development helps a lot.  I still think there needs to be a better answer than obfuscation for managed code developers, else Unity might start to grow even faster.  I really dislike how Unity is starting to fragment .Net.  I've had similar concerns for XAML land.  If it hasn't yet become obvious, I actually quite like where UWP is at now.  If there was an answer for Validation, most remaining UWP LOB limitations could be resolved.
Thank you very much for taking the time to answer these questions.

@ryandemopoulos , your remarks, more than any others give me a little piece of mind.  In particular your "probably a year or two" remark about of parallel UWP/WinUI development helps a lot.  I still think there needs to be a better answer than obfuscation for managed code developers, else Unity might start to grow even faster.  I really dislike how Unity is starting to fragment .Net.  I've had similar concerns for XAML land.  If it hasn't yet become obvious, I actually quite like where UWP is at now.  If there was an answer for Validation, most remaining UWP LOB limitations could be resolved.
Thank you very much for taking the time to answer these questions.

Could you please consider publishing at least a few parts of your code as open source?
It doesn't need to be compileable into a useable artefact.
I just want to see the code of some controls so i can use it aside with the documentation to develop my app.
I'm an old time MFC C++ programmer and i don't find the documentation satisfying at the moment. So anything will help.

Could you please consider publishing at least a few parts of your code as open source?
It doesn't need to be compileable into a useable artefact.
I just want to see the code of some controls so i can use it aside with the documentation to develop my app.
I'm an old time MFC C++ programmer and i don't find the documentation satisfying at the moment. So anything will help.

Could you please consider publishing at least a few parts of your code as open source?
It doesn't need to be compileable into a useable artefact.
I just want to see the code of some controls so i can use it aside with the documentation to develop my app.
I'm an old time MFC C++ programmer and i don't find the documentation satisfying at the moment. So anything will help.

@llothar you can find the source code of some WinUI 2 controls which are very similar (identical?) to WinUI 3 at here. For example, the NavigationView control has a complete implementation in WinUI 2.x.
Also, you can find a couple of WinUI 3 demos in C++ that used on my demos here.
Hope this helps!

Could you please consider publishing at least a few parts of your code as open source?
It doesn't need to be compileable into a useable artefact.
I just want to see the code of some controls so i can use it aside with the documentation to develop my app.
I'm an old time MFC C++ programmer and i don't find the documentation satisfying at the moment. So anything will help.

@llothar you can find the source code of some WinUI 2 controls which are very similar (identical?) to WinUI 3 at here. For example, the NavigationView control has a complete implementation in WinUI 2.x.
Also, you can find a couple of WinUI 3 demos in C++ that used on my demos here.
Hope this helps!

@Noemata WPF lacks many things; a modern compositor is only one of them. If WPF works great for you, then please use it—it’s not a goal of anyone on the WinUI team to convince people that WPF should not be used; it’s solid technology that is more than good enough for many people. WinUI 3 aims to be different: it will be a next-generation UX framework that we build next-generation UX experiences on for Windows. Starting with WPF or WinForms would not achieve that goal.

This alone, shows how little MS understands what the dev community really needs. I have talked with many devs who do desktop development and really everyone, without any exception agrees that the issue is not that we WANT to use WPF, the issue is that we MUST use WPF because UWP don't work for us. That's what's so frustrating.
I want compiled bindings. I want the better compositor and faster rendering, I want all that but what I also need for my app is:

compatibility with WinForms controls / ActiveX control
the capability to run my app as Administrator
use a modern / multi window workspace, dock panel system like Visual Studio
use of 3rd party controls ecosystems

Just to name a few. We rely on many of these components and have existing code which was written decades ago. We simply cannot effort to just rewrite everything from scratch.
In my years as MVP I've heard many promises from Microsoft they failed to deliver. Two years ago, it was promised "it doesn't matter what your project is: WinForms, WPF, UWP. You can simply mix and match all UI technologies freely".
This whole inconsistent mess, this whole "technology" situation is the reason I really hate to work on a Windows desktop app. Our app (Royal TS) is also available on mac OS and sometimes I really wish I can switch with my colleague and work on that. Granted, it is not all perfect over there.
The sad part is, many things I expect to be delivered by the OS vendor's SDK is delivered by 3rd party with far superior support and quality. Look at DevExpress's UI frameworks. Look at SVG support. Look at Avalonia (yes, they have compiled bindings and a much faster rendering pipeline and a good cross platform story).
WinForms got a lot of attention since it has been open sourced. Many great improvements from MS and the community. WPF is just "good enough" and "solid" but doesn't get any love whatsoever? Sure there are PRs related to minor things and ARM64 but what about better rendering and compiled bindings?
Sorry for the rant but I really hope that MS realizes that there's also a big number of devs with existing, large and complex code bases with many 3rd party dependencies who need a way to go forward and modernize their apps without rewriting everything.

@Noemata WPF lacks many things; a modern compositor is only one of them. If WPF works great for you, then please use it—it’s not a goal of anyone on the WinUI team to convince people that WPF should not be used; it’s solid technology that is more than good enough for many people. WinUI 3 aims to be different: it will be a next-generation UX framework that we build next-generation UX experiences on for Windows. Starting with WPF or WinForms would not achieve that goal.

This alone, shows how little MS understands what the dev community really needs. I have talked with many devs who do desktop development and really everyone, without any exception agrees that the issue is not that we WANT to use WPF, the issue is that we MUST use WPF because UWP don't work for us. That's what's so frustrating.
I want compiled bindings. I want the better compositor and faster rendering, I want all that but what I also need for my app is:

compatibility with WinForms controls / ActiveX control
the capability to run my app as Administrator
use a modern / multi window workspace, dock panel system like Visual Studio
use of 3rd party controls ecosystems

Just to name a few. We rely on many of these components and have existing code which was written decades ago. We simply cannot effort to just rewrite everything from scratch.
In my years as MVP I've heard many promises from Microsoft they failed to deliver. Two years ago, it was promised "it doesn't matter what your project is: WinForms, WPF, UWP. You can simply mix and match all UI technologies freely".
This whole inconsistent mess, this whole "technology" situation is the reason I really hate to work on a Windows desktop app. Our app (Royal TS) is also available on mac OS and sometimes I really wish I can switch with my colleague and work on that. Granted, it is not all perfect over there.
The sad part is, many things I expect to be delivered by the OS vendor's SDK is delivered by 3rd party with far superior support and quality. Look at DevExpress's UI frameworks. Look at SVG support. Look at Avalonia (yes, they have compiled bindings and a much faster rendering pipeline and a good cross platform story).
WinForms got a lot of attention since it has been open sourced. Many great improvements from MS and the community. WPF is just "good enough" and "solid" but doesn't get any love whatsoever? Sure there are PRs related to minor things and ARM64 but what about better rendering and compiled bindings?
Sorry for the rant but I really hope that MS realizes that there's also a big number of devs with existing, large and complex code bases with many 3rd party dependencies who need a way to go forward and modernize their apps without rewriting everything.

I agree with @StefanKoell but I also think about it differently.
Metro/WinRT started out as its own thing and bifurcated all Windows software, few developers and users were comfortable with how it looked, felt and behaved, and then Microsoft attempted to bring their focus back to the desktop by taking WinRT kicking and screaming into UWP.
As a programmer and as a product developer, I appreciate the hard work that's been done by many people over time to turn UWP into a desktop platform and to improve the design language. But it's just not there, and the experience is just not there either. UWP applications feel terrible. Having control borders show up when you hover over them is a cool effect, but it's horrible usability, what used to be called "mystery meat navigation" when it was an anti-pattern on web sites doing cool things with Flash for its own sake. I understand that WPF would maybe not have been the perfect paradigm for tablet applications, but the same things make Metro and its spiritual successors not perfect for desktop applications.
Does that mean I want every desktop application to look like they did in 2001? No - and if Microsoft is having another go at tightening up what's now called Fluent, I want to give them another chance. I've been waiting for Microsoft to make a coherent move on this front since Windows 7, which cleaned up many of Vista's inconsistencies and brought it forward. But if it will turn out to be one more iteration of the same formula, a lot of developers will still hold back because despite some of the technological advancements in the foundation, they won't see bringing their application over to UWP as a net positive. Microsoft needs to realize that this is the crux of the issue, and get back to formulating a desktop experience that takes advantage of what being on a full-fat PC can give you, rather than standardize on blown-up tablet paradigms in the mistaken belief that they provide a better user experience.

I agree with @StefanKoell but I also think about it differently.
Metro/WinRT started out as its own thing and bifurcated all Windows software, few developers and users were comfortable with how it looked, felt and behaved, and then Microsoft attempted to bring their focus back to the desktop by taking WinRT kicking and screaming into UWP.
As a programmer and as a product developer, I appreciate the hard work that's been done by many people over time to turn UWP into a desktop platform and to improve the design language. But it's just not there, and the experience is just not there either. UWP applications feel terrible. Having control borders show up when you hover over them is a cool effect, but it's horrible usability, what used to be called "mystery meat navigation" when it was an anti-pattern on web sites doing cool things with Flash for its own sake. I understand that WPF would maybe not have been the perfect paradigm for tablet applications, but the same things make Metro and its spiritual successors not perfect for desktop applications.
Does that mean I want every desktop application to look like they did in 2001? No - and if Microsoft is having another go at tightening up what's now called Fluent, I want to give them another chance. I've been waiting for Microsoft to make a coherent move on this front since Windows 7, which cleaned up many of Vista's inconsistencies and brought it forward. But if it will turn out to be one more iteration of the same formula, a lot of developers will still hold back because despite some of the technological advancements in the foundation, they won't see bringing their application over to UWP as a net positive. Microsoft needs to realize that this is the crux of the issue, and get back to formulating a desktop experience that takes advantage of what being on a full-fat PC can give you, rather than standardize on blown-up tablet paradigms in the mistaken belief that they provide a better user experience.

Thanks @marb2000 and @ryandemopoulos for answering some questions.
Are you willing to answer me as well on the state of these open issues regarding WinUI 3 for desktop:
WebAuthenticationBroker not working
https://github.com/microsoft/microsoft-ui-xaml/issues/3692
Drag/Drop not working
https://github.com/microsoft/microsoft-ui-xaml/issues/2715#issuecomment-733202320
Execution Alias not working
https://github.com/microsoft/microsoft-ui-xaml/issues/3441
Protocol Activation not working
Tried both MSIX and registry

Thanks @marb2000 and @ryandemopoulos for answering some questions.
Are you willing to answer me as well on the state of these open issues regarding WinUI 3 for desktop:
WebAuthenticationBroker not working
https://github.com/microsoft/microsoft-ui-xaml/issues/3692
Drag/Drop not working
https://github.com/microsoft/microsoft-ui-xaml/issues/2715#issuecomment-733202320
Execution Alias not working
https://github.com/microsoft/microsoft-ui-xaml/issues/3441
Protocol Activation not working
Tried both MSIX and registry


fix(checks): Enforce timing mutual exclusions on BOLD data only

Begins to address #1906 by at least containing the metadata complaints to BOLD files, which were the data that were intended to be checked. @tsalo Should this be expanded to include ASL as well?

It seems like it could apply to ASL, but TBH I don't know for sure. I say we include ASL and change it if an ASL user raises a valid concern.


After moving a frame using drag and drop, the wrong frame is selected (Firefox)

Steps to reproduce :

open Piskel in Firefox
open a piskel with 4 distinct frame
using the mouse/drag-and-drop, move the first frame to the another position

Expected : the moved frame should be selected
Actual : the new 'first' frame gets selected.
Some investigation :
We have a moved frame F, going from index i1 to i2.
After the mouseup releasing F, the currentFrame is set to the new index of F, which is i2 At the next call of the render loop, all UIs will redraw accordingly.
However on Firefox a click event is also fired after the mouseup event, which triggers another call to setCurrentFrame. This one is based on the data-attribute of the event target. Since the UI has most likely not had time to redraw yet, F's data-attribute is still i1.
Could be a bug/limitation of jquery's sortable util.

Fixed by @zoeesilcock


selector grammer not work when the selector element is lazy-loaded

https://github.com/imageslr/chrome-tab-modifier/commit/aab6a43bd9f932873758a8f8cae389b37341375f#commitcomment-47379301

Please try the newest commit: https://github.com/imageslr/chrome-tab-modifier/commit/a2bae00d7b5f87ac38c493b4a0a367cb0ef7dd96
@dnknn

@imageslr  I want to ask, how to use repo,
You can load unpacked extension in project `/dist` folder. ?


ClassNotFoundException: Didn't find class app.rive.runtime.kotlin.core.Fit

Its Just keep Crashing
A/DEBUG: Abort message: 'JNI DETECTED ERROR IN APPLICATION: JNI GetMethodID called with pending exception java.lang.ClassNotFoundException: Didn't find class "app.rive.runtime.kotlin.core.Fit" on path: DexPathList[[zip file "/data/app/~~Y_KJptZvbnNQ_bjaj7XaEQ==/-0ntkYT-AqrtiZ71SmUqe2w==/base.apk"],nativeLibraryDirectories=[/data/app/~~Y_KJptZvbnNQ_bjaj7XaEQ==/-0ntkYT-AqrtiZ71SmUqe2w==/lib/arm64, /data/app/~~Y_KJptZvbnNQ_bjaj7XaEQ==/-0ntkYT-AqrtiZ71SmUqe2w==/base.apk!/lib/arm64-v8a, /system/lib64, /system/system_ext/lib64, /system/product/lib64]]
        <app.rive.runtime.kotlin.RiveAnimationView
            android:id="@+id/animationView"
            android:layout_width="0dp"
            android:layout_height="0dp"
            android:elevation="5dp"
            android:visibility="visible"
            app:layout_constraintBottom_toBottomOf="@+id/imageView17"
            app:layout_constraintBottom_toTopOf="@id/guidelineBottom"
            app:layout_constraintLeft_toLeftOf="@id/guidelineLeft"
            app:layout_constraintRight_toRightOf="@id/guidelineRight"
            app:layout_constraintTop_toBottomOf="@id/guidelineTop"
            app:riveAutoPlay="false"
            app:riveResource="@raw/graph_3"
            />

hi @mjtalbot , the issue got fixed somehow, I couldn't reproduce the issue either,  And it was crashing in every device and emulator I tried., then  I checked the gradle.build file and I realised that the crash only happens when
minifyEnabled true , and  shrinkResources true
if i set minifyEnabled to false then its not crashing anymore


Validate that private clusters do not have overlapping network ranges

Is your feature request related to a problem? Please describe.

When I am creating a private workload cluster (CAPA or CAPZ) I have to specify a network range (AWS VPC / Azure VNet) that is not overlapping with management cluster network range and also not overlapping with any other workload cluster network range withing the same management cluster.
In order to specify a non-overlapping network range for the new workload cluster, I have to check network ranges of all other aforementioned clusters and calculate the next available network range which is big enough for a Kubernetes cluster.
All this described work is currently manual, thus very much error prone. When an invalid network range is specified, the error is not visible immediately, as all cluster resources are applied and cluster creation is initiated. The error can be noticed later when cluster creation fails, because peering between management cluster network and the newly created workload cluster network cannot be established.
Describe the solution you'd like

When I try to create a cluster, an admission controller validates all applied resources (e.g. AWSCluster, AzureCluster). That validation admission controller checks if used network range is valid, which for private clusters means that all workload clusters and the management cluster itself are using non-overlapping network ranges. In case of a validation failure, cluster creation is not started and an appropriate validation error message is immediately visible on the front-end side (e.g. kubectl output).
Describe alternatives you've considered

In addition to a validation admission controller written in Go, another possible solution could be validation with Kyverno.
Front-end validations, such as schema validation, are not powerful enough, because here the validation is "dynamic" and a valid network range is different every time.
Additional context

Nothing at the moment.
Outcome

When setting custom CIDR ranges, they will get validated to not already being in use.

the ClusterNetwork struct  specifies the different networking parameters for a cluster. The "critical" CIDRs we care for are provider specific as they are mostly used for some VPN peering stuff.
But as discussed right know, let's try to keep the new validation controller compatible for CAPZ and CAPA
// ClusterNetwork specifies the different networking
// parameters for a cluster.
type ClusterNetwork struct {
	// APIServerPort specifies the port the API Server should bind to.
	// Defaults to 6443.
	// +optional
	APIServerPort *int32 `json:"apiServerPort,omitempty"`

	// The network ranges from which service VIPs are allocated.
	// +optional
	Services *NetworkRanges `json:"services,omitempty"`

	// The network ranges from which Pod networks are allocated.
	// +optional
	Pods *NetworkRanges `json:"pods,omitempty"`

	// Domain name for services.
	// +optional
	ServiceDomain string `json:"serviceDomain,omitempty"`
}

Maybe it's also worth to check if the experimental ipam controller could take over some parts of requirements: KEP: https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/proposals/20220125-ipam-integration.md


firefox can not by "navigator.appVersion" get system info

Chrome:
> navigator.appVersion
< "5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36"
> navigator.oscpu
< undefined

Firefox:
> navigator.appVersion
< "5.0 (Windows)"
> navigator.oscpu
< "Windows NT 6.1; WOW64"

> navigator.oscpu || navigator.appVersion

see http://mdn.io/oscpu
see http://mdn.io/appVersion

Why do you want that information to be returned from os.release() (at least that's what I assume you're talking about)?


Use ssh to connect clickhouse fail

I use dbeaver 6.0.4
Test ssh success

but connect clickhouse fail

Generally Clickhouse works fine with SSH.
Check you connection settings. Maybe server listens different IP address and localhost/<IP_ADDRESS> isn't a valid address.


Scheduler admin tools

This is some work I hacked together locally for last year’s scheduling, rebased and tidied up a little.
It’s all under the general theme of giving more fine-grained control over the scheduling. Features include:

Adds the ability to import/export schedules, so that an admin can run the annealer on a local machine (which is cheaper and far faster than running it on Heroku) and upload the results.
Allows incremental scheduling, primarily to support scheduling additional sessions after the scheduler has already run.
Provides a hacked-up but workable rake UI for restricting specific presenter / timeslot combinations, e.g. “Sally can’t present after 2:00”. (My fee for the pro bono work on the scheduler is that I get to use this feature to prevent myself from having to present in the first timeslot.)
Improved stats on the scheduler’s results.

Sorry to submit this all as a big blob, but that’s how it ended up in the heat of last year.

Coverage remained the same at 92.523% when pulling ac0e65b96f8e5fe447839ef530907c17d1ab1815 on scheduler-admin-tools into 6ab940ddc4b9c3d8c309eec0ba660514f89cef48 on master.

@pcantrell thanks for this. As always your work is awesome and appreciated.
If you can find the time down the road I'd love a few more details (comments maybe) about what each of these variables mean and why ... specifically about things like opening_count room_size small_slots big_slots and what a best_possible_score actually means.
Thanks!

Thanks for wading through it. Agreed, much more documenting & clarifying needed. Assigned myself an issue so I don’t forget.


Updated versions and code simplification

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] I have signed the Adobe Open Source CLA.
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Can you switch the dependencies to dynamic version? Can you also add a warning about dynamic dependency and a link to this page https://developer-stage.adobe.com/client-sdks/documentation/manage-gradle-dependencies/


Newest update of Phasmophobia does not fully extract the game assets and gives error

Game name: Phasmophobia
Engine version: Unity
Platform: Windows/PC
Error message: Magic number doesn't match
Stack trace:    at uTinyRipperGUI.Exporters.ShaderDXExporter.Export(ShaderWriter writer, ShaderSubProgram& subProgram)
at uTinyRipperGUI.Exporters.ShaderHLSLccExporter.Export(ShaderWriter writer, ShaderSubProgram& subProgram)
at uTinyRipper.Classes.Shaders.ShaderSubProgram.Export(ShaderWriter writer, ShaderType type)
at uTinyRipper.Classes.Shaders.SerializedSubProgram.Export(ShaderWriter writer, ShaderType type, Boolean isTier)
at uTinyRipper.Classes.Shaders.SerializedProgram.Export(ShaderWriter writer, ShaderType type)
at uTinyRipper.Classes.Shaders.SerializedPass.Export(ShaderWriter writer)
at uTinyRipper.Classes.Shaders.SerializedSubShader.Export(ShaderWriter writer)
at uTinyRipper.Classes.Shaders.SerializedShader.Export(ShaderWriter writer)
at uTinyRipper.Classes.Shader.ExportBinary(IExportContainer container, Stream stream, Func3 exporterInstantiator)    at uTinyRipperGUI.Exporters.ShaderAssetExporter.Export(IExportContainer container, Object asset, String path)    at uTinyRipper.Project.AssetExportCollection.Export(ProjectAssetContainer container, String dirPath)    at uTinyRipper.Converters.ProjectExporter.Export(String path, GameCollection fileCollection, IEnumerable1 files, ExportOptions options)
at uTinyRipper.GameStructure.Export(String exportPath, Func`2 filter)
at uTinyRipperGUI.MainWindow.ExportFiles(Object data)

I have this same problem but no one in this community seems to give us an answer, I've had this problem for months and no one responded.

No promises, but you can try my AssetRipper fork.


Refactor tests

Problems

tests contain a lot of duplicate code that can be refactored for example creating test data on the fly and training models needed to test certain functions
do not make full use of pytest fixtures everywhere. for example for creating temp folders

In addition to this, it seems that we are testing on tox AND pytest:
        $(VIRTUALENV)/bin/pytest --disable-warnings -v --cov=grants_tagger
        $(VIRTUALENV)/bin/tox

Isn't the second one redundant?

i think that pytest is testing with the development environment installed while tox with the library installed. these are two different environments.

That a makes sense - but the tests are the same - in principle we could drop one?

That a makes sense - but the tests are the same - in principle we could drop one?

definitely but its like running the same tests on different python versions


add django support extension for vscode

It is the most loved django extension for vscode

I'm not against adding IDE plugins, but we currently don't have an IDE category. I think having an upper-level IDE category would be fine, but I am not sure I want a top-level VS Code category. I'm am also not comfortable saying "best" and "popular" given these contexts.
I'll let @wsvincent weigh in, but I'm leaning towards letting this bake a bit more.

Hope its ok now. @jefftriplett @wsvincent


Proposal: Use standard k8s labels

What
Use standard/recommended k8s labels to identify applications/components resources (https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/)
Why
Tekton applications need to find resources belonging to other applications (dashboard needs to talk to pipelines and triggers, triggers needs to talk to pipelines, etc.).
The current process for identifying resources in dependent applications is lacking flexibility, often relying on resource names (see https://github.com/tektoncd/dashboard/blob/83f7c6a9746470f5fb391a160779d855f8db8e00/pkg/endpoints/dashboard.go#L110-L130 for example).
Also, version labels are not completely clear to me:https://github.com/tektoncd/pipeline/blob/c11c6afa4904216d7b1c7a7a44c0b703e6093ccd/config/controller.yaml#L23-L24
What is the difference between pipeline.tekton.dev/release and version ?
How
We could establish a clear list of applications/components labels and document them.
These labels should be set on all resources and we should use them to lookup the necessary resources instead of relying on names.
Such a list could look something like this:

application
component
app.kubernetes.io/name
app.kubernetes.io/component
app.kubernetes.io/version

pipelines
controller
tekton-pipelines
controller
v0.11.3

pipelines
webhook
tekton-pipelines
webhook
v0.11.3

triggers
controller
tekton-triggers
controller
v0.4.0

triggers
webhook
tekton-triggers
webhook
v0.4.0

dashboard
controller
tekton-dashboard
controller
v0.6.1

webhooks-extension
extension
tekton-webhooks-extension
extension
v0.6.1

webhooks-extension
validator
tekton-webhooks-extension
validator
v0.6.1

Other labels (app.kubernetes.io/instance, app.kubernetes.io/part-of, and app.kubernetes.io/managed-by) could be used to reflect the deployment instance and the technology used to deploy (kubectl/helm).
Benefits
The benefits would be:

Normalized labelling
More flexible lookup process
Easy to document/test

In general, I am +:100: on this :wink:

Also, version labels are not completely clear to me:
https://github.com/tektoncd/pipeline/blob/c11c6afa4904216d7b1c7a7a44c0b703e6093ccd/config/controller.yaml#L23-L24
What is the difference between pipeline.tekton.dev/release and version ?

None, and if we would follow k8s labels, we would add one more. pipeline.tekton.dev/release is an internal label (let's say :sweat_smile:), version is the label that follows istio guidelines (see https://istio.io/docs/ops/deployment/requirements/).

The benefits would be:
* Normalized labelling
* More flexible lookup process
* Easy to document/test

/kind feature
/kind cleanup

None, and if we would follow k8s labels, we would add one more. pipeline.tekton.dev/release is an internal label (let's say 😅), version is the label that follows istio guidelines (see https://istio.io/docs/ops/deployment/requirements/).

Thanks for clearing this up.
As it is specific to istio, it should ultimately be the responsibility of the end user to set them i guess, and should not participate in the context of looking up resources.
Reading the k8s docs again i wonder if the labels should be (tekton-pipelines controller example)
labels:
  app.kubernetes.io/name: tekton-pipelines
  app.kubernetes.io/component: controller

or
labels:
  app.kubernetes.io/name: controller
  app.kubernetes.io/part-of: tekton-pipelines

The second one looks closer to the docs. If we use this, we probably should omit the app.kubernetes.io/component label as it doesn't really bring any more  infos.

/assign

Closing as all related PRs were merged.


Add smoke test

The smoke test failed in ci, but apart from that it seems this URL is not covered by authentication. That is a prerequisite to sort out, we can allow local requests to be whitelisted but I would expect this port to refuse everything requested without authentication like in https://github.com/elifesciences/elife-dashboard-formula/blob/master/salt/elife-dashboard/config/etc-nginx-sitesenabled-app.conf#L33-L34

Once I can actually add new tables to the prod DB (Django auth, sessions etc..) I can use the prefered authentication methods.

Uhm still red?

This is now a 401 auth failure, which is expected with the current configuration as we are not passing it the auth details required by nginx.
What strategy should be used to resolve this? do we have another smoke test example where nginx authentication is in play?

Yes, my standard solution is to allow all local requests so that the smoke tests can skip authentication:
https://github.com/elifesciences/journal-formula/blob/master/salt/journal/config/etc-nginx-sites-available-journal.conf#L117-L119

Latest failure was due to the db being dropped by the original test suite and there not being a db present when the smoke tests run. This PR should resolve this.

There are other PRs running simultaneously to the one fixing the database teardown, so after that one is merged a new highstate and recreation of the tables is needed as a one-off.

Now green.

It is a bit weird that we were seeing so many changes, since most of them (the database cleanup) were already in develop.


[LOC] Back-Translation "新規-ラベル"→"New-Label"

🛑 IMPORTANT: You can get your feedback addressed faster if you use the comment section for the article in which you encountered a problem (if available).

Link to article:
Tell us where exactly a problem occurs.
"https://docs.microsoft.com/ja-jp/powershell/module/exchange/policy-and-compliance/new-label?view=exchange-ps"
Problem:
What's wrong with the article?
[LOC] Back-Translation "新規-ラベル"→"New-Label"

@RyanKing77 could you please take a look? If it's not in your content, let me know, I can provide a contact.

@TinaMcN

@OfficeGlobal, please uplift this topic to human translation. @Soran-M FYI this is an MT overlocalization issue in PowerShell content.

Working on a fix

@hyoshioka0128 , @TinaMcN the article was HumanTranslated and published live

@OfficeGlobal , @TinaMcN - Fixed.
Closed #2314.
Thanks.


update stylelint

stylelint was updated to 6.0.0 yesterday.
Please review this.

Thanks for the MR! This will be released in v2 due to breaking changes in stylelint.
Currently there seems to be an error reporting issue in stylelint v6, so I'll need to postpone merging this (hopefully the wait won't be long).

Just released 6.0.2 which I hope fixes thid.

@chatii2412 could you please change version to ^6.0.2 and commit title to

chore(package): update stylelint dependency to v6

and I will merge. Thanks in advance.

Point of curiosity (from someone not especially familiar with npm or gulp conventions): why does gulp-stylelint have a dependency on<EMAIL_ADDRESS>requiring a major version bump to upgrade to ^6.0.2, rather than a peerDependency on<EMAIL_ADDRESS>which could then reasonably be changed to stylelint@>5.4.0,<7.0.0 without needing a major version bump in gulp-stylelint itself?

@olegskl
I changed dependency version to ^6.0.3 and the commit message, too.
And stylelint's patch version is keep changing now, you can just close it and update yourself.
Thanks.

@chatii2412 thanks, merged and released this morning.
@chris-morgan both approaches seem to be valid. Personally, I just think it's easier for users to download gulp-stylelint and don't bother figuring out which peer dependencies need to be installed as well. I'm open to change if there's sufficient demand for using stylelint as a peer dependency.


feat: add more languages and fix small bug

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 0.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
0

Relevant Lines:
39

💛  - Coveralls

Just the following translations are missing since they were added by @diegograsso after we asked for the translations
     'There is no credentials associated with this account.': 'No se encontraron credenciales asociadas a esta cuenta.',
      'Please configure your credentials in the RIF identity manager.': 'Por favor, configure sus credenciales en RIF Identity Manager',
      'Go to RIF Identity Manager': 'Ir a RIF Identity Manager',
      Retry: 'Retry',

@lucachaco I can add them :D


Google Summer of Code 2023

Since I see a lot of activity here recently, I wanted to check if you guys are interested in applying for Google Summer of Code. This would be as sub-org via Debian or Python.
This could help to get some issues and tasks done and support those 2 orgs (they get a stipend for each mentor). This project already joined GSoC in 2018 via Debian. I can be a backup mentor, but will focus on Borg and Vorta this year. We would need 2 mentors who are active on the project. You would choose and assign tasks and track the progress. E.g. with GH issues or the Kanban feature.
Pinging @rmilecki, @bosd @alexis-via

I'm sorry but my free time is really limited and I find time only occasionally to work on this project (every few months).
I may be able to find some time for reviewing but no promises.

I'm interested, but the deadline seems way to close for me.
To draft the ideas and tasks for this project.

If you apply via PSF, it's pretty quick. Feel free to copy from the page I put together for Vorta just now.
https://github.com/borgbase/vorta/wiki/Google-Summer-of-Code-2023-Ideas
For tasks, just pick the tasks you find important and elaborate a bit.

This one can be closed now, we did not make the application deadline


Can I use "Assign unique names" feature for Xamarin.Forms?

Hi, there, I have a Xamarin.Forms project and the target platform is UWP. I try to use "Assign unique names" to create the automation Id but I cannot find Name Interactive Elements. in the Tool menu. Can I apply it for Xamarin.Forms? Thanks.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: d0a48be5-f89a-6133-7af7-a9abf1519968
Version Independent ID: 64f4314d-4d96-5f46-99f3-e1bea2ddf1fb
Content: Set a Unique Automation Property for UWP Controls for Testing - Visual Studio
Content Source: docs/test/set-a-unique-automation-property-for-windows-store-controls-for-testing.md
Product: visual-studio-windows
Technology: vs-ide-test
GitHub Login: @Mikejo5000
Microsoft Alias: mikejo

@yanxiaodi -- Yan, thank you for your question. Please consider these resources:

https://social.msdn.microsoft.com/Forums/vstudio
https://www.stackoverflow.com
https://www.reddit.com/r/VisualStudio/

As well, you might also consider using the Report a Problem tool to report the issue.
cc @Mikejo5000 for awareness


Add config to override default ssh port for install scripts. #780

@elonlo
please commit pr to branch dev-db. because dev cannot be submit for now.

okay


Update devDeps to use<EMAIL_ADDRESS>Add fbjs dependency

Importing emptyObject from fbjs fixes the tests when using<EMAIL_ADDRESS>but I'm happy to discuss other solutions.
Fixes #58
Running npm test gives the following warnings which I might have a look at fixing:
Warning: Surface.getDOMNode(...) is deprecated. Please use React.findDOMNode(instance) instead.
Warning: TestComponent.getDOMNode(...) is deprecated. Please use React.findDOMNode(instance) instead.
Warning: setProps(...) and replaceProps(...) are deprecated. Instead, call React.render again at the top level.
Warning: `require("react").render` is deprecated. Please use `require("react-dom").render` instead.

Thinking about it, using || in a devDependency doesn't really make much sense.
Would it be better to simply use "react": "^0.14.0-a" in dev, so tests run against the latest version by default?

Thanks for doing this :)

Would it be better to simply use "react": "^0.14.0-a" in dev, so tests run against the latest version by default?

Yes, and then we can update all of these when we ship final.

Done.

Good catch, thank you.

Published as 0.13.2.