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

[anawishnoff]

This community call has passed. You can watch the recorded version here:

https://youtu.be/kVbu2ZWCMhU

---

Hi all -

The next WinUI Community Call will be on Wednesday March 18.

We'll be broadcasting live on Microsoft Teams:

https://aka.ms/winuimarchcall

Details

Date: Wednesday March 18
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 online call directly with members of our engineering team.

Please leave questions/topics/feedback!

We'll be dedicated a portion of the call to answering your questions, so please leave comments in this issue if there are any questions or topics you'd like us to cover next week!

If you've tried out the new WinUI 3 Alpha Feb 2020 update then we'd also love to talk about any feedback you might have so far on WebView2 or anything else.

Agenda

1. Quick intro/recap on WinUI
2. Community Spotlight: TabView updates & sample demo with Marcel (@chingucoding) and Steven (@stmoy )
3. Brief update on this month's progress
4. Deep-dive with @ryandemopoulos: Demystifying how WinUI 3 relates to Desktop Apps, Win32, UWP, WinUI 2, and other frameworks like Xamarin.Forms and React Native.
5. Q&A - we'll answer your questions from this issue (leave a comment!) and anything that comes up during the call!

We'll have a few dev team leads around this month to help answer questions on the call and in the live chat stream.

[alvinashcraft]

I'm looking forward to the call. Are the issues with ObservableCollection expected to be resolved when the preview ships? Could the team talk about progress with known issues? Thanks!

[nickrandolph]

Grab the ICS for the community call from the new WinUI website:
https://microsoft.github.io/microsoft-ui-xaml/WinUICommunityCall.ics

[andrew-boyarshin]

It would be great to have more information on the recently published MUX.Window spec. The spec covers very basic things.

• Will MUX.Window have a cool modern UWP look by default even on Win32? (ApplicationFrame-like, titlebar+window control buttons)
• What about proper styling? Glow (like VS), shadow, theme (Force/Prefer Dark/Light), border width (possibly 0) and color?
• Will it be possible (and simple) to specify custom draggable area and extend view into titlebar?
• What about rendering? An option to create no redirection bitmap (enabling bug-free acrylic on Win32) would be great to have.
• Will it be implemented for Win32 as an ordinary window with a single XAML Island? Or in a proper way (full-XAML window without an Island), without unnecessary layer of complexity and potential issues related to window event handling?
• Digging a bit deeper, will the window be in ZBID_UIACCESS band when the user has UIAccess token? Will topmost be supported, at least on Win32?

Looking forward to hearing more information on the matter.

P.S. I also hope we will see CsWinRT and .NET 5.0 for UWP Preview SDK soon, but I suppose that's not WinUI team responsibility.

[andrew-boyarshin]

By the way, #2007 is closed by recent TabView PR, but it would be nice to have it confirmed WinUI TabView has feature-parity with WCT version _and_ the ability to make it look exactly like in Microsoft Edge (UWP, not the Chromium one).

[stmoy]

By the way, #2007 is closed by recent TabView PR, but it would be nice to have it confirmed WinUI TabView has feature-parity with WCT version and the ability to make it look exactly like in Microsoft Edge (UWP, not the Chromium one).

TabView customizability (and the customizability of _all_ controls) is an important part of the feature set. This has been an area of active investigation lately (#2100). Philosophically, we want to support reasonable control styling and customization across our controls; however, enabling TabView look exactly like _ye olde_ UWP Edge isn't a high priority for the team. We'll continue to invest in ensuring that our controls are aligned with the latest Fluent patterns (including rounded corners, shadows), while supporting appropriate customization options.

[Quarle]

Is there a timeframe for when features like the XAML Ribbon are due to be implemented for feature parity with other frameworks?

[andrew-boyarshin]

_not a question for the call_

@stmoy it's great to hear WinUI team doesn't forget about customization options.
I really like Fluent design system, and I welcomed all incremental changes introduced over the last 5 years (well, Fluent was only formulated like 2-3 years ago, but the general idea was right there from the start of Windows 10). All but rounded corners. I accept them now, in all controls, except for top-level ones: window (ContentDialogs, context menus and Flyouts look fine rounded), TabView, Ribbon (if only we had one), NavigationView. I hope, that a way to preserve the rectangular shape in aforementioned controls will still be there in WinUI 3 and later versions. Acrylic appearance should just be the ability to customize the background of the whole TabView; I think this should work even now. Full-height items (without that padding) — not so sure.
I really want WinUI to be a good (better) alternative to WPF. It is somewhat disappointing now and again: old .NET runtime (UWP fault, but still), excessively locked down API surface (again UWP), lack of customization options and 3rd party controls. Official Ribbon implementation is still missing too, despite clearly existing and being used in Office UWP apps. I just hope WinUI will remain solid, but make progress with more thoughts on customizability and presenting the developers with a choice, especially when something changes in the design spec.

[saint4eva]

Please shade more light on the UWP, WinUI and .NET 5 story

[sharpninja]

The disparity in functionality of Window in UWP and Win32 feels like WinUI desktop is just WPF reskinned. I was personally hoping that functionality would work the same except where sandbox restrictions apply, meaning that targeting Win32 should match UWP 100% plus things UWP cannot do.

[massijay]

Will WinUI 3 be backward compatible down to Windows 10 build 15063 like WinUI 2? Or it'll keep the current (3 alpha) compatibility down to build 17134?

[JosephusPaye]

It would be great to have more information on the recently published MUX.Window spec. The spec covers very basic things.

• Will MUX.Window have a cool modern UWP look by default even on Win32? (ApplicationFrame-like, titlebar+window control buttons)
• What about proper styling? Glow (like VS), shadow, theme (Force/Prefer Dark/Light), border width (possibly 0) and color?
• Will it be possible (and simple) to specify custom draggable area and extend view into titlebar?
• [...]

Good points @andrew-boyarshin! I would add:

• Will it be possible to make the window frameless (no border or title bar)?
• Will it be possible to make the window transparent (with mouse events over transparent areas falling through to whatever is behind the window)?

Those are both features from WPF that are not achievable with current UWP, and would be great to have in WinUI. They're critical for apps like launchers, e.g. something like Alfred on Windows.

[mveril]

Can you talk about titlebar cutomisation consistency between UWP and Desktop app model

2124

[chiefklondog]

• How difficult is it to / what is the process for extending native controls in C#. What level of control do you have - are there things that are really only exposed on the native side?

• For enterprise desktop development where performance matters, what - if any - is the pressure to write your own controls natively to continue to get high performance out of the framework. Is the expectation that all performance critical user controls be written that way in the future?

• Modern UI has a much bigger focus on supporting clean icons. Will there be better support for things like font glyphs or SVGs to make them less painful to use? Are there any plans to have a Microsoft made, community driven, library of icons to help reduce the dependencies on 3rd party icon sites for core/common icons and help provide continuity between different desktop applications?

[lhak]

Will it be possible to just use AppWindows in the win32 app model? My use case is to use (non-UI) libraries that do not work in the UWP context. All UI-related parts can be completely UWP/WinUI.

[TonyHenrique]

WinUI Proposal: Allow the App to Print without showing the Confirmation Dialog to user https://github.com/microsoft/microsoft-ui-xaml/issues/2126

[anawishnoff]

Join us on teams for this call due to technical issues:

https://aka.ms/winuimarchcall

[DHitchenUK]

Will Preview 1 support visual basic project types ?

[marb2000]

@andrew-boyarshin and @sharpninja The MUX-Window work is split into several phases. We just make public the P0 APIs, that fundamental ones. Once this phase is done, we will prioritize the second round of APIs. Win32 window APIs are very powerful, and let you know to do a lot of things. To unblock your scenarios we will expose the underneath HWnd in Win32 so you can manipulate the window using Win32 APIs meanwhile MUX-Window doesn't have a convenient API.

Q: Will MUX.Window have a cool modern UWP look by default even on Win32?
It's on the backlog. The first Preview will have the Win32 window style.

Q: What about proper styling? Glow (like VS), shadow, theme (Force/Prefer Dark/Light), border width (possibly 0) and color?
Given there won't be proper WInUI3 APIs for doing this in the first phase, the Window class will expose the underneath HWnd so you can manipulate the window using Win32 APIs.

Q: Will it be possible (and simple) to specify custom draggable area and extend view into titlebar?
No in the first phase. It's on the backlog.

Q: What about rendering? An option to create no redirection bitmap (enabling bug-free acrylic on Win32) would be great to have.
Please, open a feature request describing the scenario. This is not being tracked at the moment.

Q: Will it be implemented for Win32 as an ordinary window with a single XAML Island? Or in a proper way (full-XAML window without an Island), without unnecessary layer of complexity and potential issues related to window event handling?
It's being implemented properly, for sure :) I trust in our developer team. If you are curious about, we are using DesktopWindowXamlSource and other APIs to expose the XAML framework in Hwnds.

Q: Will the window be in ZBID_UIACCESS band when the user has UIAccess token?
This is out of our radar. Can you create a feature request, please?

Q: Will topmost be supported, at least on Win32?
I think you can set the topmost flag if you get the Hwnd of the Window. But having an API in MUX.Window will help, for sure.

[marb2000]

@lhak,
Q: Will it be possible to just use AppWindows in the win32 app model?
Unfortunately, the current plan is that AppWindow won't work in WinUI 3.0 neither UWP nor Win32. In the backlog for future releases.

[marb2000]

@JosephusPaye
Q: Will it be possible to make the window frameless (no border or title bar)?
This is in the backlog, but it's no part of the phase 1.

Q: Will it be possible to make the window transparent (with mouse events over transparent areas falling through to whatever is behind the window)?
Same answer as above. However, making the Window transparent is a little more challenging, given we need to make transparent the XAML framework and this no part of phase 1.

[andrew-boyarshin]

@marb2000 thank you for your answer. I didn't quite catch the very important detail about phases. Which will make into WinUI 3 RTW?

It's great to have Hwnds, and it does solve a lot of problems. Still, WS_EX_NOREDIRECTIONBITMAP can only (to the best of my knowledge) be applied during window creation. It would be great if window creation flags API makes it into WinUI 3.

There is one more point. I trust the WinUI developer team too. But it's much easier to reuse XAML Islands code (like DesktopWindowXamlSource), than go one level deeper. The problem with this approach is that there is HWND-UWP-HWND-UWP sandwich in the resulting visual tree. A lot can go wrong, not to mention the amount of overhead it implies. Just look at this: hit test first received by Win32 window, then passed to DesktopWindowXamlSource, hit test again, then internal Hwnd hit test again, finally we are in the target UWP land, do the hit test again. Don't forget to marshal data every step of the way, we are passing COM boundaries after all. I read the early XAML Islands design doc (pity such informative docs are so rare) and see the list of issues (scrolling, UI synchronization issues, etc) with Hwnd-based interop, and the simpler way uses 2 Hwnds! It is obvious this can be greatly simplified to match what CoreWindow appframe does under covers, but it takes a little more effort. I hope WinUI will take the better option, not the simpler one.

[Sergio0694]

Hey @alvinashcraft - sorry for the ping, I was just curious to what "issues with ObservableCollection<T>" were you referring to in your question 🤔

Were you referring to the missing APIs that are being worked on in https://github.com/dotnet/runtime/issues/18087?
Or is there some other issue with that specific type I'm missing?
Thanks! 😄

[alvinashcraft]

Hey, @Sergio0694. No problem. I was talking about the INotifiyPropertyChange issue with ObservableCollection that is referenced on the MS Docs page for the Alpha release:

The .NET interfaces System.ComponentModel.INotifyPropertyChanged and System.Collections.Specialized.INotifyCollectionChanged are projected into the WinRT Windows.UI.Xaml namespace as Windows.UI.Xaml.Data.INotifyPropertyChanged and Windows.UI.Xaml.Interop.INotifyCollectionChanged, respectively. However, WinUI 3.0 depends on interfaces in the Microsoft.UI.Xaml namespace, so types that implement these .NET interfaces do not function well with WinUI 3.0. To work around this issue, your type should implement the corresponding Microsoft.UI.Xaml interfaces.

As a result of this issue, ObservableCollection does not work well in conjunction with WinUI 3.0.

I've seen this issue when using ObservableCollection as an ItemsSource on a ListView in the Alpha.

[sharpninja]

Why can't the less common one inherit the more common? The ObservableCollection works everywhere.

---

From: Alvin Ashcraft [e-mail]
Sent: Wednesday, March 18, 2020 6:08:25 PM
To: microsoft/microsoft-ui-xaml [e-mail]
Cc: The Sharp Ninja [e-mail]; Mention [e-mail]
Subject: Re: [microsoft/microsoft-ui-xaml] 👩‍💻📞 WinUI Community Call (March 18, 2020) (#2104)

Hey, @Sergio0694https://github.com/Sergio0694. No problem. I was talking about the INotifiyPropertyChange issue with ObservableCollection that is referenced on the MS Docs pagehttps://docs.microsoft.com/en-us/uwp/toolkits/winui3/ for the Alpha release:

The .NET interfaces System.ComponentModel.INotifyPropertyChanged and System.Collections.Specialized.INotifyCollectionChanged are projected into the WinRT Windows.UI.Xaml namespace as Windows.UI.Xaml.Data.INotifyPropertyChanged and Windows.UI.Xaml.Interop.INotifyCollectionChanged, respectively. However, WinUI 3.0 depends on interfaces in the Microsoft.UI.Xaml namespace, so types that implement these .NET interfaces do not function well with WinUI 3.0. To work around this issue, your type should implement the corresponding Microsoft.UI.Xaml interfaces.

As a result of this issue, ObservableCollection does not work well in conjunction with WinUI 3.0.

I've seen this issue when using ObservableCollection as an ItemsSource on a ListView in the Alpha.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/microsoft-ui-xaml/issues/2104#issuecomment-600902610, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AD3GCLCOPVTZOVYPMI6SIBTRIFH6TANCNFSM4LGVVDEA.

[harvinders]

@anawishnoff Do we have the recording please?

[maxkatz6]

@sharpninja
ObservableCollection works only on .Net, when WinUI supports more platforms.

[ranjeshj]

@alvinashcraft Thanks for providing the details. The problem with ObservableCollection that you see in the Alpha bits is tracked by #1557.

[deanchalk]

Id really like to watch a recording, unfortunately I was unable to make the call

[anawishnoff]

@harvinders @deanchalk Recording will be uploaded shortly. :)

[anawishnoff]

Recording has been uploaded! Check it out here:

https://youtu.be/kVbu2ZWCMhU

[infoequipt]

Ryan asked what "cross platform means to you". From an enterprise desktop app perspective, I want WinUI apps to be an alternative to developing web apps. Since web apps are by nature "cross-platform" (depends on your def of platform), we need something that will run on the prevalent desktop OS's in business. Windows, Mac OS, iOS and Linux Desktop. I'm on the fence about iOS because, I particularly care about workstations with keyboard and mouse.

Do I care if a Fluent-looking app is running on OS X or Ubuntu? I will take consistent UI functionality over some religious argument that its not being true to the native OS. Do businesses care? I don't know, I think they care more about spending less time developing/tweaking per platform/OS.

WinUI 3 targeting desktop OS's other than Windows is going to be a game changer. I would hope that leadership would see its importance and rank it high on the to-do list after 3.0 ships.

One other thought, why (as an industry) are we spending so much time on PWAs, Electron, Blazor/WASM to get around the performance of browser-based apps? Simple. Because there is no (free) alternative to build and deploy desktop apps cross-platform. MS is the one company that can challenge the status quo and give developers and alternative to the browser (the establishment). If you're picturing someone throwing a large hammer at a television, sit and ponder that irony.

Also, Ryan, Savoy, Miguel, Ranjesh and Ana thanks again for doing these calls.