microsoft / microsoft-ui-xaml

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

👨‍💻☎ [Cancelled] WinUI Community Call: October 20, 2021 #6050

Closed gabbybilka closed 2 years ago

gabbybilka commented 2 years ago

Update (10/19/2021) 📢: The October WinUI Community Call has been cancelled - we'll see you in November.

Instead of a live Q&A, we'll be answering your questions posted here, For additional questions, please feel free to open up separate issues for them on the repo.


Please join us for the October 2021 edition of the WinUI Community Call. This event will be live-streamed to YouTube at the following link: https://youtu.be/h4apI79wt4o

Details

Date: October 20, 2021 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 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 sharing WinUI roadmap updates and info about the latest WinUI 3 release in Windows App SDK Preview 2 (#6049). We'll also be joined by folks from the React Native for Windows team to share latest updates and give an overview of how RN4W integrates with and layers on top of WinUI.

Agenda

Q&A Code of Conduct

Leave us your questions in the comments on this issue or live in the YouTube chat during the stream!

lhak commented 2 years ago

@Scottj1s Nice to hear that xcopy deployment is targeted for 1.0. Was just asking because on the winappsdk roadmap this is shown as not supported for 1.0.

ryandemopoulos commented 2 years ago

No matter why the meeting is cancelled, thanks for your magnificent works! I think the fluent development experience on recent-version WinAppSDK has been pleasing most of us. I want to know which step have Mica & DesktopAcrylic Controllers reached? Are them nearly completed? Concerning the coming Preview3, will it contain the mere bug fix? Or part of preliminary features will be out too?

Mica and BG Acrylic won't make 1.0 unfortunately -- I'm hopeful those will be possible in 1.1.

From a WinUI perspective, Preview 3 will be mostly bug fixes, although some noteworthy advancement on unpackaged support for apps too.

ryandemopoulos commented 2 years ago

@Scottj1s Nice to hear that xcopy deployment is targeted for 1.0. Was just asking because on the winappsdk roadmap this is shown as not supported for 1.0.

I'm confused -- the roadmap is here and it says that we'll have unpackaged support in 1.0 for WinUI 3 apps. Isn't that what you asked about?

lhak commented 2 years ago

@ryandemopoulos My question is specifically about self-contained unpackaged apps. This is shown as not supported for 1.0 but as far as I have understood @Scottj1s correctly, this will actually be supported.

lhak commented 2 years ago

Will there be a new experimental release that contains all of preview 3 (especially the newer styles) and has the experimental features (like multi-window support) enabled?

kmgallahan commented 2 years ago

@Scottj1s Regarding C# hot reload => Simply commenting out a Debug.WriteLine call results in a System.ExecutionEngineException.

Screenshot 2021-10-20 134600

Regarding XAML hot reload => changing something as simple as displayed text doesn't result in any live changes.

Both of these things were working in Preview 1.

Edit:

I just noticed from this comment that hot reload support in VS 2019 looks like it's been dropped for at least 6 months...

michael-hawker commented 2 years ago

Referring to CommunityToolkit/WindowsCommunityToolkit#4171 (comment) As I understand it, WCT was awaiting 2.7 styles in WinUI 3 in order to update to experimental (or now, I assume, preproduction preview 3.) Are the style changes there and will MVVM be available soon? I'm at CommunityToolkit.Mvvm" Version="7.0.3" with Microsoft.ProjectReunion.WinUI" Version="0.8.2".

Nearly all of the 2.7 controls/styles will be in WinUI 3 in the WinAppSDK 1.0 launch this year -- they'll be in the next preview we release very soon. One exception to this is Mica support -- unfortunately that is more complicated (like Background Acrylic) and likely won't be possible until next year -- I'm hoping the v1.1 release.

Unsure about the MVVM question. @michael-hawker, can you comment?

@terrycox the CommunityToolkit.Mvvm package is an artifact of our build pipeline being split for the new package names with WinUI 3. Once Preview 3 ships, we'll be shipping an update and that'll be resolved. Immediately afterwards, we'll be splitting out our .NET specific packages to their own repo and won't have this de-sync issue with our .NET based packages for future versions, everything will move to CommunityToolkit.* for .NET specific things.

codendone commented 2 years ago

Hello! Unfortunately I came across on multiple limitations of WinUi 3 as GUI framework. Here is my questions (I will very appreciate if you cover these ones):

  1. What is about Vulkan support. My application heavily uses Vulkan engine to render different scenes. I want to easily migrate to WinUi (but it seems like there is no direct support). Some custom control with vulkan rendering will be enough.
  2. This one is related to the previous question (it's kind of workaround). Will WinUi support of including native controls (especially for native win32 HWND) in nearest releases? (Here is list of related issues Question: How to migrate a simple Win32 app to WinUI 3.0 #3812, Discussion: Legacy Pond (Legacy control container in XAML) for XAML Desktop #1833, #Discussion: Vulkan embedding #3291). I analyzed the WinUI 3 application. I noticed that it does not use native win32 children (it seems like that they are custom drawn, except for top level window - WinUIDesktopWin32WindowClass) This is problem because Vulkan API requires native HWND . (Just as example - WPF provides similar feature)
  3. Why does API not have effective way to override appearance of any controls. (I know that composition can be applied for custom draw controls, but it's very ineffective to render such primitives as Line, Rectangle, Path because they are derived class of Shape. It has overhead (for example due implementation, each of such instances allocated memory on heap etc). Just as example - WPF proposes direct rendering to Visual object, its content has render instructions which will be processed later on GPU - I did not find similar way in WinUI 3). It's related to How to render content of Control object? #6036
  1. There is no direct support for Vulkan. Some discussion of that and alternatives are in #5193.
  2. WinUI3 does not currently have HwndHost (like WPF) to directly support hosting child HWNDs. Depending on your needs, you could put a child HWND in the app yourself and size/position it appropriately. This isn't easy if you need that HWND to take keyboard focus have a proper Accessibility tree, but if it is only for custom rendering these complications likely won't apply.
  3. WinUI has largely focused on the user interface of an application rather than being a renderer for application content, and complex custom rendering is less common for the user interface. More capabilities have been added in recent years, but even those focus on shapes and paths. Note that there are both XAML elements for Shape and Path as well as Composition primitives via CompositionSpriteShape, which moves the shape handling/rendering down to the composition layer. If the rendering capabilities you're looking for here are shapes/paths, then perhaps Win2D is a better fit?
marb2000 commented 2 years ago

@kmgallahan kmgallahan

@Scottj1s Scott Jones FTE Regarding C# hot reload => Simply commenting out a Debug.WriteLine call results in a System.ExecutionEngineException.

Screenshot 2021-10-20 134600

Regarding XAML hot reload => changing something as simple as displayed text doesn't result in any live changes.

Both of these things were working in Preview 1.

Edit:

I just noticed from this comment that hot reload support in VS 2019 looks like it's been dropped for at least 6 months...

XAML Diagnostics Tools like Hot-Reload, Live Visual Tree, In-App Command Bar, etc are only supported on VS2022 Preview 5/6 and GA. They are no longer supported in VS2019.

thatsofia commented 2 years ago

@ryandemopoulos

Are there going to be updates to the styles of WPF so users don't have to rely on external dependencies?

And perhaps open-sourcing UXTheme?

Regarding WPF and UxTheme, both are good ideas, but neither are planned at this time. We're focusing our resources on bringing new value primarily to WinUI, as we have a lengthy ToDo list in terms of features to add and bugs to fix.

That's sad for numerous reasons and is really hypocritical of MS. I need not say more but our end users are the ones that hurt (and of course us 😢)

And a more user-facing question I have is whether click and drag support for menus is coming. I'm not sure if there's an issue in this repo already but people (in my circles at least) including myself have noticed this. And hey... isn't Paint using XAML islands now?

Could you help me understand what "click and drag support for menus" means? Is this re-ordering within a menu or something like that?

Turns out that there is an issue: #815. It's strange that no one on the WinUI team has ever used this behaviour in their own day-to-day lives. I didn't even need to get that feedback from UX in my case as I already saw it myself.

@stmoy

It looks like the Xbox app for Windows uses an old version of RNW (and hence WinUI). It also doesn't use MSIX? What's up with that?

Thanks for reaching out! We work closely with Facebook to ensure that React Native for Windows stays aligned with the RN Core versions - in fact, we just released v0.66 of RNW to coincide with the release of v0.66 for RN core. Even so, it takes teams a while to update to the latest version (including folks that we work closely with like the Xbox team).

Thanks for the reply! Just four big customers is uh... not what I was expecting at this stage.

MEK3DK commented 2 years ago

Will Width and Height properties for a Window be supported in 1.0? It seems funny to release a UI framework for Windows where you cannot set Width and Height.

(I know there is a bug for it: #2731)

@ryandemopoulos Thanks for all your answers, but I think you missed this one.

riverar commented 2 years ago

Becoming open source has been much, much more difficult for us than we anticipated. I personally vastly underestimated the amount of effort it has required. It's more than just "release the code" -- it required us to decouple from the OS and private API calls (which took months of work but is mostly completed), but also still requires us to change our build systems so that we can accept PRs, comb thru millions of lines of code for other needed changes, updating our testing infrastructure, and change our internal planning processes too.

Please consider publishing the source without CI and without consideration of PR acceptance -- that's not required. Some of us would just like a code dump so can better understand the framework, build better apps/tooling, and/or use it as a quick reference. Or consider minimally sharing with Microsoft Code Center Premium partners so they can help others from a troubleshooting perspective. Thanks!

marb2000 commented 2 years ago

Will Width and Height properties for a Window be supported in 1.0? It seems funny to release a UI framework for Windows where you cannot set Width and Height. (I know there is a bug for it: #2731)

@ryandemopoulos Ryan Demopoulos FTE Thanks for all your answers, but I think you missed this one.

No. There won't be Width and Height properties for MUX.Window objects in v1.0. You can always use some helpers like this one: https://github.com/marb2000/DesktopWindow

robloo commented 2 years ago

Please confirm status of releasing WebView2. This is still marked as preview and cannot be used with Store apps. I'm strongly hoping this will be done for 2.8. Even if there are issues, leave it up to app developers to decide with their own testing if it is acceptable to release. (My use case is so simple it works perfectly already).

https://github.com/microsoft/microsoft-ui-xaml/issues/6224

-original- https://github.com/microsoft/microsoft-ui-xaml/issues/5610 https://github.com/microsoft/microsoft-ui-xaml/pull/5708

apierini commented 2 years ago

Hello, is there an ETA for xaml islands in WinUI 3? I've seen on the roadmap that they are "Planned for a future update", but a more detailed schedule would be very appreciated.

We have a big win32 desktop app that we would like to modernize and we need to choose bewteen waiting for Win UI 3 xaml islands, using Win UI 2 xaml islands or using some alternative approach (ie WPF hosted inside HWND).

Any suggestions are welcome.

Andrea

llothar commented 2 years ago

Any suggestions are welcome.

Just wait. Like me and others learned to wait for 14 years since the last exciting Win32 improvement in 2008.

Calling the current state of Windows App SDK Version as 1.0 is this typical agile development result of a failed (underestimated) project. XAML Island for Win 1.0 was the BIG unique sales point for Project Reunion. I doubt anyone can answer you as they will need a postmortem to know what they have to plan for the next roadmap.

My christmas wish is that nobody in the high level management withdraws resources from "Windows App SDK Version 2.0" so i have something to look for in Q4 2022.

gabbybilka commented 2 years ago

Closing this issue, please feel free to open up a new issue with questions, bug reports, or discussion topics.

pubtom commented 2 years ago

If you need .NET>5 in UWP please give a vote on this: https://developercommunity.visualstudio.com/t/Add-NET-678-support-to-UWP/1596483