search

microsoft / microsoft-ui-xaml

Windows UI Library: the latest Windows 10 native controls and Fluent styles for your applications
MIT License
6.36k stars 678 forks source link

👩‍💻📞 WinUI Community Call (March 18, 2020) #2104

Closed anawishnoff closed 4 years ago

anawishnoff commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

andrew-boyarshin commented 4 years ago

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

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 commented 4 years ago

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 commented 4 years ago

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.

andrew-boyarshin commented 4 years ago

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 commented 4 years ago

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

sharpninja commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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:

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 commented 4 years ago

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

2124

chiefklondog commented 4 years ago
lhak commented 4 years ago

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 commented 4 years ago

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

anawishnoff commented 4 years ago

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

https://aka.ms/winuimarchcall

HEIC-to-JPEG-Dev commented 4 years ago

Will Preview 1 support visual basic project types ?

marb2000 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

From: Alvin Ashcraft notifications@github.com Sent: Wednesday, March 18, 2020 6:08:25 PM To: microsoft/microsoft-ui-xaml microsoft-ui-xaml@noreply.github.com Cc: The Sharp Ninja ninja@thesharp.ninja; Mention mention@noreply.github.com 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 commented 4 years ago

@anawishnoff Do we have the recording please?

maxkatz6 commented 4 years ago

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

ranjeshj commented 4 years ago

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

deanchalk commented 4 years ago

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

anawishnoff commented 4 years ago

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

anawishnoff commented 4 years ago

Recording has been uploaded! Check it out here:

https://youtu.be/kVbu2ZWCMhU

infoequipt commented 4 years ago

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.