Microsoft-ui-xaml: 👩‍💻📞 WinUI Community Call (April 15, 2020)

Created on 7 Apr 2020  ·  40Comments  ·  Source: microsoft/microsoft-ui-xaml

This community call has passed. Thanks to all of our presenters and team members for contributing!

You can catch a recording of the call here: https://www.youtube.com/watch?v=DdpBMUXwtDY&feature=youtu.be&t=1981

Details

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

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

Please leave questions/topics/feedback!
We'd like to spend part of the time answering your questions again, so please leave comments in this issue if there are any questions or topics you'd like us to cover next week!

Agenda

  • Intro/agenda
  • Status Report for WinUI 3
  • Community Guest Spotlight

    • We will be welcoming Ginny Caughey, who’ll be talking about her modernization plan that includes WPF in the future. So far, she’s used our Alpha to port over a UWP app to a WinUI 3 app in about an hour(!)

  • Windows Community Toolkit Spotlight

    • @michael-hawker will be joining us to introduce the WCT, talk about how the relationship between the WCT and WinUI, and demoing exciting controls from the WCT.

  • WinUI 2.4: HierarchicalNavigationView demo
  • WinUI 2.4: ProgressRing demo
  • WinUI 2.4: Radial Gradient Brush demo
  • Q&A

Ask away!

discussion hot

Most helpful comment

In the WinUI Community Call (Feb 19, 2020) it was mentioned that Xbox app support and Full Gamepad Input support was At Risk for WinUI 3.0.

My questions:

  • How will game pads be supported in WinUI 3.0?
  • Is there anything you can comment on in terms of Xbox app support?
  • Is there anything you can comment on in terms of Windows IoT Core support?

All 40 comments

In App and HostBackdrop Acrylic. What is Microsoft's commitment on keeping it, supporting it, extending it, with Windows 10X, 10, Xbox, etc

Is there scope to come up with an alternative fallback than just a solid colour? Passing through the Desktop Wallpaper? #2236 #1523 #1493 #761 #256

In App and HostBackdrop Acrylic. What is Microsoft's commitment on keeping it, supporting it, extending it, with Windows 10X, 10, Xbox, etc

Is there scope to come up with an alternative fallback than just a solid colour? Passing through the Desktop Wallpaper? #2236 #1523 #1493 #761 #256

This. A faux acrylic is needed to keep consistency.

It would be nice to have some sort of roadmap for this issue discussed in the community call:

  • When will a fix be; when will BG acrylic function normally again?
  • What alternative will we have in the meantime (plain grey is not good, we need faux acrylic or something like what has been discussed) until the issue is fixed
  • As @mdtauk stated - where will acrylic be extended too? Right now it is still missing from NavigationView, TabView, and much more, and I believe this should definitely be reassessed.

If whoever is working on WinUI 3.0 features, could give us some info about:

  • What is preventing Acrylic being there day one?
  • How Microsoft thinks they will be able to make it work after 3.0 ships?
  • How long after 3.0 will we have to wait?
  • And what could stand in for Acrylic in 3.0 timeframe?

@carmellolb When I said extending Acrylic, I didn't mean what controls should get it by default next - but additional Materials, making it work on more devices and scenarios, improving performance, that kind of thing.

If whoever is working on WinUI 3.0 features, could give us some info about:

  • What is preventing Acrylic being there day one?
  • How Microsoft thinks they will be able to make it work after 3.0 ships?
  • How long after 3.0 will we have to wait?
  • And what could stand in for Acrylic in 3.0 timeframe?

@carmellolb When I said extending Acrylic, I didn't mean what controls should get it by default next - but additional Materials, making it work on more devices and scenarios, improving performance, that kind of thing.

Ah okay. I think all of these things are important.

WinUI 3.0 and Windows 10X could be the opportunity to create a better, more performant Acrylic 2.0 - for UWP and WinUI Desktop. Which could also be made to work for WPF windows, and maybe even Edge on Windows 10

WinUI 3.0 and Windows 10X could be the opportunity to create a better, more performant Acrylic 2.0 - for UWP and WinUI Desktop. Which could also be made to work for WPF windows, and maybe even Edge on Windows 10

Very good point - this could be an opportunity to modernize older applications and bring Fluent Design effects to more than just what we have currently.

Responding to @mdtauk's comment - which I can't seem to find here even though I received an email notification:

Yes, that is a great point. Aero Glass's structure could very well serve as some sort of base for a new type of acrylic - it was not as performance impacting and I bet it can be restructured some way that lets it appear like acrylic, but have a similar functionality to Aero Glass.

Responding to @mdtauk's comment - which I can't seem to find here even though I received an email notification:

Yes, that is a great point. Aero Glass's structure could very well serve as some sort of base for a new type of acrylic - it was not as performance impacting and I bet it can be restructured some way that lets it appear like acrylic, but have a similar functionality to Aero Glass.

I couldn't remember if the Win7 Aero Glass did blurring, so I deleted the comment in case I was mis-remembering - but if it did, that code/ability could be part of the solution to making it work for WinUI 3.0

I too would love to see Acrylic stay with us. Even if a faux acrylic, it would still be nice to have.

Would also love to see older apps that use WPF to be able to natively make use of WinUI.

I also feel like the current Xaml Islands system is a bit cumbersome to use. For one, we still depend on a UWP project.

I think it would be great to have some kind of package for WPF/WinForms that contained all WinUI controls wrapped with properties we can directly access and bind.

What is happening with the new ScrollViewer? If I am not mistaken in one of the community calls it was mentioned that it would be release as part of WinUI 2.4. However, in last community call it was absent from the list of items to be released in WinUI 2.4.

If it is not going to be part of 2.4, can someone shed some light what is holding it off and when can we expect it?

I wish for a toggle to be able to have Acrylic ignore OS transparency settings.

I went as far as to port the WinUI acrylic brush to C# to accomplish this in my own app, but it would be nice to not have to maintain this myself :-)

You still fall back due to a lack of hw accelerated rendering, but hopefully that’s much less common for my users.

Fallback being forced to a solid color instead of a completely separate brush is also unfortunate.

It’d also be nice to get a XAML Islands sample for .NET that doesn’t use WPF to host the island. I rolled my own Win32 windowing code in .NET and used the Hosting APIs directly to avoid loading all of WPF for a full screen XAML scenario.

Regarding WinUI controls on WinForms and WPF, will they be visible at design time like a normal control?

On a side note:

I went as far as to port the WinUI acrylic brush to C# to accomplish this in my own app, but it would be nice to not have to maintain this myself :-)

@nc4rrillo do you happen to have that open-sourced? I'd love to give it a try.

I wish for a toggle to be able to have Acrylic ignore OS transparency settings.

That seems like a bad idea in my opinion. Disregarding options users have selected creates distrust in the platform and software and is generally a bad move from a users perspective.

Fallback being forced to a solid color instead of a completely separate brush is also unfortunate.

Yes, hopefully there will be more options in the future.

Since currently Acrylicbrush with Hostbackdrop is not available with WinUI 3 Alpha and won't be with the release of WinUI 3, would it be possible to allow the usage of the WUXC Acrylicbrush in UWP apps to at least allow that brush in a scenario where it already is supported?

Or would this not be possible due to technical limitations associated with the switch of namespaces?

Since currently Acrylicbrush with Hostbackdrop is not available with WinUI 3 Alpha and won't be with the release of WinUI 3, would it be possible to allow the usage of the WUXC Acrylicbrush in UWP apps to at least allow that brush in a scenario where it already is supported?

Or would this not be possible due to technical limitations associated with the switch of namespaces?

I think they have said mixing Namespaces wont be allowed

First, let me say I'm excited on where WinUI is headed and look forward to RTM. If I may, I would like to see more love with the following:

  1. Attach more issues to milestones. This will allow community to understand what is being offered and considered complete with each release. For example, there has been no activity with WinUI 3.0 milestone for over 2 months (understanding there is work being done behind the scenes).
  2. Granted v3 needs to be released, it would be nice to see some possible features coming in vNext. Like what high-level things are being considered? Controls, VS tooling, etc. Maybe something that can be included at MS Build as a treat 😄.

Thanks again.

Thanks guys!

@MikeHillberg
Would appreciate any input on validation with UWP / WinUI / WCT.

@chingucoding I like the idea @shaheedmalik had of a faux acrylic interim solution. If it exposed the same API surface until the backdrop host was supported officially, it would make upgrading apps easier.

Then basically it could just provide a generic frosty looking background that's light or dark based on the application theming settings?

So basically a AcrylicBrush that always behave like BackgroundSource=Backdrop ? That would also be a suitable interim solution.

So basically a AcrylicBrush that always behave like BackgroundSource=Backdrop ? That would also be a suitable interim solution.

There is In App Acrylic also, is that also not going to work in WinUI 3.0 - or is it only HostBackdrop

What do you mean by "in app acrylic"? 😅

What do you mean by "in app acrylic"? 😅

There is the Host Backdrop Acrylic, where the desktop and windows behind show through.

Then there is In App Acrylic, where the UI behind the element is visible.

image
image

Ohhhh I see. Yes In app Acrylic is an AcrylicBrush with BackgroundSource=Backdrop while the background acrylic is an AcrylicBrush with BackgroundSource set to HostBackDrop. I am currently not sure if there will be an acrylicbrush in the WinUI 3 release or none at all. Currently in the WinUI 3 alpha the component is completely missing afaik.

Ohhhh I see. Yes In app Acrylic is an AcrylicBrush with BackgroundSource=Backdrop while the background acrylic is an AcrylicBrush with BackgroundSource set to HostBackDrop. I am currently not sure if there will be an acrylicbrush in the WinUI 3 release or none at all. Currently in the WinUI 3 alpha the component is completely missing afaik.

It's missing ThemeShadow too - so apps are going to feel like Windows 10 launch edition apps when it comes...

Ohhhh I see. Yes In app Acrylic is an AcrylicBrush with BackgroundSource=Backdrop while the background acrylic is an AcrylicBrush with BackgroundSource set to HostBackDrop. I am currently not sure if there will be an acrylicbrush in the WinUI 3 release or none at all. Currently in the WinUI 3 alpha the component is completely missing afaik.

It's missing ThemeShadow too - so apps are going to feel like Windows 10 launch edition apps when it comes...

That is what we need to avoid. The apps would be inconsistent all over the place.

I just want to know when the issue I raised can be resolved. It has been a long time since it was raised but there has been no corresponding fix #2040 #1372 #1820

@chingucoding @mdtauk As far as I am aware, in-app acrylic will indeed be in WinUI 3.0 (just not HostBackdrop acrylic). Team to comment please if I'm wrong here.

I'm really curious as to how they're gonna pull off support for both WinForms, WPF and UWP at the same time. Hope it'll be possible to just drag-drop controls around.

Is WinUI Desktop going to have a UWP style app lifecycle events? I saw @marb2000 post in twitter with OnLaunched() and OnSuspending() APIs as part of App<T>.

image

In the WinUI Community Call (Feb 19, 2020) it was mentioned that Xbox app support and Full Gamepad Input support was At Risk for WinUI 3.0.

My questions:

  • How will game pads be supported in WinUI 3.0?
  • Is there anything you can comment on in terms of Xbox app support?
  • Is there anything you can comment on in terms of Windows IoT Core support?

It’d also be nice to get a XAML Islands sample for .NET that doesn’t use WPF to host the island. I rolled my own Win32 windowing code in .NET and used the Hosting APIs directly to avoid loading all of WPF for a full screen XAML scenario.

@nc4rrillo Take a look to this site where you can find Win32, WPF, abd WinForms samples of XAML Islands.

s WinUI Desktop going to have a UWP style app lifecycle events? I saw @marb2000 post in twitter with OnLaunched() and OnSuspending() APIs as part of App<T>.

Some events will be supported, like OnLaunched, and others like OnSuspending won't be called.
More details at:
https://github.com/microsoft/microsoft-ui-xaml-specs/blob/Win32/active/Win32/Window_and_Application_API_Spec.md

Kindly shade more light on .NET and WinUI. And make it easy to develop WinUI apps using VS Code.

Which new controls can we expect in WinUI 3?

Can @marb2000 talk a bit more about why WinUI Desktop apps won't use CoreWindow? Do these separate code paths provide a decent enough method to abstract away the differences between the traditional window design vs CoreWindow? (i.e. Caption button size/removal, extending content into titlebar, etc.)

Finally, what role will AppWindow play in this once it becomes a component of a later WinUI 3.x release? I assume it will follow the same principles as described in the relevant design spec.

Will we see updated docs that reflect the change from UWP/Win32 => "Windows Apps" ?

Is there anything I can do to contribute to these docs before they're published? Perhaps WinRT, Win32, and .NET should be introduced better in the docs to reflect this change.

Finally, is there any work being done on bringing elements of newer WinUI (rounded corners, updated acrylic, fluid animations) to in-box apps like Settings and various shell surfaces?

Some clarity for me, When will UWP (WinUI 3.0) work with .net core and which version of .net core ? Current version (.net core 3.1) or do we have to wait for .net 5 at the end of this year. If it is .net 5 is it already possible to create a UWP app with .net 5 preview and WinUI 3.0 ?

As usual, I'd like a status update for SwapChainPanel support :)

Will we be able to multi-target WinUI class libraries for UWP and Win32? Or will we even need to multi-target, but a single DLL that has a WinUI dependency will "just work" on both platforms?

Was this page helpful?
0 / 5 - 0 ratings