👩💻📞 WinUI Community Call (Febuary 19, 2020) #1972
Comments
msft-github-bot
added
the
needs-triage
|
I have a question regarding the Windows 10X development. To develop for it I need the emulator, when will there be support for AMD processors (nested virtualization)? Can we count on the Windows 10 2003 version? More related to WinUI, based on #1958, whats the future of Live Tiles? |
|
AMD Ryzen support is preventing me from running the Emulator, so any word on when that will be rectified will be good to hear. |
|
This is the official wording (https://docs.microsoft.com/en-us/dual-screen/windows/get-dev-tools):
If you want more info you should probably contact dualscreendev@microsoft.com. I doubt WinUI is the correct team to ask Emulator specific questions. |
|
Thanks @Felix-Dev - that's correct, the docs are the best place to get the latest status on the 10X emulator, and that email address is the best contact for other 10X questions that aren't specific to WinUI. |
|
Fair enough, will have to wait until Microsoft are ready to talk about it. Looking at Windows 10X, Win32 apps run in a VEIL container. What about WinUI 3.0 non UWP apps? Will they appear to run as native UWP apps do on 10X? |
|
@mdtauk Since WinUI Desktop apps are not native UWP apps, I don't think they will run in the UWP container. I believe they will run in the mentioned Win32 container as they will have (all) the capabilities of Win32 apps. |
|
I'm also interested to know what the plan is for WinUI app isolation going forward. From an enterprise perspective, we need isolation/sandboxing and capability control (not user opt-in). So, putting this out there as a topic for Miguel.. |
This is a little disappointing. Win32 apps seem to exhibit different windowing behaviour, and darken the screen when they are in the foreground. So switching also behaves differently. Using a Xaml UI, is have hope a WinUI Desktop app would be a best of both worlds scenario at least on the surface to the user |
|
@mdtauk As the current 10X emulator image released to us is still very early I'm pretty sure the issues/behavior you noticed (I did too in my tests) will be addressed/altered until release (i.e. I also have Win32 apps which just fail to load right now). That said, I will be happy to be corrected on the WinUI Desktop app container on 10X. My current thinking is based on what we've been told about WinUI Desktop so far (Win32 app model), the 10X presentation It's certainly a good question to ask the team! |
|
@Felix-Dev according to the same video you mentioned (How Windows 10X runs UWP and Win32 apps) at minutes 20:18 says that hybrid apps (Win32/UWP) are not supported (yet?) and my understanding is that an app which uses XAML Island is an hybrid app. |
|
Q1) When will SwapchainPanel be available in WinUI? This is absolutely essential for what I and many others do. Q2) Since SharpDX isn't being supported by it's creator anymore, will Microsoft step up and provide compatibility between SharpDX and WinUI's hardware rendering surfaces? Does MS even see a story for hardware rendering with C# without SharpDX? And I don't care about Unity, I mean for unrestrained, free form graphics development, for making our own graphics tools, engines and non-Unity games in C#. And I also don't mean Win2d, I require full hardware rendering capability (DirectX). Q3) Applications lack the ability to turn off TaskBar and TitleBar popups when the mouse is moved to the top and bottom edge of the screen. This is a deal-breaker for many games (and maybe some apps) which utilize screen edge in their own UI's for things like camera pan or popups. When will this be fixed (this may be a Windows issue, but it needs to be driven by an API, so it's relevant to WinUI). Q4) Can we get WinUI to include the CoreWindow (IFrameworkView) app model for when we want to bypass Xaml and render directly to a window bound Swapchain. It might sound slightly odd, requesting that WinUI provide a non-Xaml surface. But I think CoreWindow belongs with XamlWindow (called Window in UWP) in the same library, also separated from UWP to make it available in .net 5. Assuming .net 5 will be able to target non-uwp as well as uwp. There is currently no modern C++ application model outside of UWP - game devs must use legacy c code (Win32) to write application layers for games or graphics apps. Neither is there a modern desktop application model in .net core. UWP's solution for CoreWindow is effective and comfortable to use. It just needs to exist outside of UWP (for both C++/non-uwp and .net 5). Another benefit of pulling out CoreWindow from UWP is that it provides a way to directly port code from UWP to .net 5 (and C++ if it ever gets a non-uwp modern application model). Game dev's cannot use UWP until windowing behavior is changed and distribution story is sorted out. It's been so long that it looks like Microsoft doesn't even understand the problem. So we have to try to pull these API's outside of UWP. If UWP was fixed we wouldn't need to. And further comment from issue 1215 If you replace Win32 Window with CoreWindow for non-contained / non-Xaml scenarios, and also provide CoreWindow to .Net 5 Non-UWP then we can have a unified app/window model across Windows for non-Xaml work. That makes more sense than holding onto Win32 FOR EVER or making up new App models. Why should we have to rewrite the application layer just because we want to switch between contained and non-contained execution (for example between UWP and Win32) - that's a typical problem which faces game dev's today, they can't commit to UWP because they need Win32 distribution freedom. So they are forced to use HWnd or .Net Framework app models. If the UWP app/window model was made available for non-uwp-contained apps, no problem, we could write the same code for the application layer and compile for both MS Store and other stores from the same code base. |
|
@leoniDEV Much of this is still speculation what exactly is meant by "hybrid apps". See this twitter thread for example where it is said that XAML Island apps don't belong into that category (Matteo Pagani works at Microsoft as a @Gavin-Williams There will be two flavors of WinUI: WinUI UWP and WinUI Desktop. With WinUI UWP you will be able to create full UWP apps which will run in the UWP container on Windows 10X. Then there is WinUI Desktop which will enable Win32 apps to have full access to the UWP UI APIs (XAML, composition, input,... - excluding a few APIs like WinUI has been written in C++ from the ground up so it can be used in an unmanaged app context. As I stressed above, my writing |
|
I would like to hear more about any thoughts on potentially being able to use other programming languages, such as Java, Python, JavaScript etc, when building apps using WinUI / Microsoft UI. I know there is a project called Xlang (cross-lang) - which essentially seems like what .NET should have been, a better COM. How does that relate to WinUI? |
|
xlang is essentially a cross-platform open source version of the Windows Runtime (WinRT), though it wasn't going to be fully compatible. The purpose of WinRT is what you said, interoperability between languages, and it is based on COM. WinUI's APIs are built on WinRT which is how it supports both C++ and C#. There are other languages with various levels of support for WinRT, including Python, Rust (this is one I've personally worked on) and JavaScript, but as far as I know none of them (yet) support WinUI - supporting WinUI is particularly difficult because its Composition and XAML APIs heavily depend on a type system feature called composable types (essentially a form of implementation inheritance) which other WinRT and UWP APIs don't use and which can be tricky to map to other languages' type systems. I've actually been thinking a lot recently about how Rust could best support composable types (and thus WinUI). It's certainly possible but am not yet sure how natural I can get it to feel for developers. Basically, any language should be able to support WinRT if someone puts in the work to create a projection, but depending on the design of the language it can sometimes be tough to map WinRT type system constructs to the type system of the language in a way that feels natural. |
|
xlang looks dead to me. C++/WinRT wasn't ever really finished - it was left with bugs and a very odd-ball usage story, making it undesirable for the average developer. I struggled for many, many hours to get C++/WinRT working, and failed to do what I did in 30 minutes with C++/CX. And C++/CX was easier to use by a long shot. If Microsoft wants these cross language tools to be usable by the Average Joe, they need to put a team of people onto the problem and not leave it to Kenny Kerr to do all the work by himself. He's got some great ideas. But these tools need broad appeal, and i think he needs help to bring these products to maturity and to be all they can be. |
|
For now UWP and it's successor WinUI is not ready for LOB applications There are several problems we are facing
Do you think that WinUI can overcome this limitations and become next LOB ready framework for the next 10 years. Or it time to move forward to electron blazor app ) |
|
I have a couple of issues with the current state of WinUI. C++/WinRT is still a very poor developer's experience compared with C++/CX tooling and overall developer experience. If we are expected to deal with WinUI components written in C++, having at very least 1:1 coverage for what C++/CX tooling is capable of is to be expected. Being standard C++17 is of no use to me if my productivy suffers versus just using C++/CX, and it takes twice as long to write a UWP component or XAML based UI. Which leads to my second question, the main reason to having to deal with C++ on UWP/WinUI, is because Microsoft has dropped the ball in any kind of DirectX bindings to .NET languages. So will WinUI ever provide support for XNA like replacement, or WPF 3D scenegraph? Apparently we only get radio silence here, and are forced to go into community projects like MonoGame or full blown engines like Unity. When is Win2D finally be made part of WinUI? Currently it looks to be in maintainence mode with uncertain future. Currently it is becoming very hard to still keep selling the UWP dream, as the amount of listners around my soap box keeps diminishing. |
|
When will Windows 10X UI elements make their way to desktop Windows 10? |
|
@carmellolb 2022-2025? Edit: MS will probably delete this, because it proposes a schedule for product delivery, which doesn't exist and is therefore misleading ;) |
|
@Felix-Dev "WinUI Desktop .. will enable Win32 apps to have full access to the UWP UI APIs .. excluding a few APIs like CoreWindow. Excluding CoreWindow? OMG - That's the first and most important API that should be pulled out of UWP. It's the most foundational API that provides the basic window functionality. It needs to be universal, inside and outside the UWP container. Until it's brought out we can't have a common code base for the application layer and we are stuck with legacy Win32 c code in C++ or whatever .net core is going to provide (another Window class again?) for C#. Please Microsoft - Just like you're providing XamlWindow both in and out of UWP, please also provide CoreWindow both in and out of UWP. |
|
About the call: why did you move away from Teams? YouTube didn't work out so well on the last one. |
|
From #1215 (comment):
The team also said it is looking to provide APIs like CoreApplicationViewTitleBar.ExtendViewIntoTitleBar for WinUI Desktop as well so we might be able to get the best of both worlds. The full power of Win32 windowing design (i.e. no titlebar/100% custom titlebar, app window < required minimum size, no taskbar button,...) and the new modern UWP customization APIs. (For UWP, we probably have to wait for AppWindow V2 to have windowing capabilities which are close to the current Win32 windowing ones.) @jesbis Question regarding WinUI Desktop: In issue #1939 it has been pointed out that toast notification activation does not work for MSIX packaged desktop apps on (at least) 1909 as mentioned in the docs:
While I have to wait and see if the mentioned fix will be backported to affected OS versions for desktop bridge apps my question is: Will WinUI Desktop apps provide the out-of-the-box toast activation feature quoted above (so without having to use a COM Activator) on all of the WinUI targeted Windows 10 versions? (Or any similar toast activation concept.) |
|
@Felix-Dev From the documentation seems that XAML Island don't strictly implies an hybrid app, you could call the UWP XAML hosting API directly from your Win32 app at the expense of loosing some functionality, like use of custom controls, if I understand correctly the docs (and the note in the docs): Host a standard UWP control in a WPF app using XAML Islands
|
@Gavin-Williams, @pjmlp have you opened issues in the cppwinrt repo for the issues you're finding? Or are they problems specific to WinUI that you could open issues for in this repo? We're actively working on C++/WinRT support so it would be great to hear any details on what's not working well for you. We're using it ourselves too - new WinUI features are all in C++/WinRT, as are our apps using it (e.g. calculator). |
|
Starting to catch up on some questions:
WinUI is specifically the UI layer and doesn't include other aspects of the UWP app platform like the app model for suspend/resume, background tasks, etc. For UWP apps, it can specifically replace
@Felix-Dev we haven't explored the idea yet of better single-instance support for win32 apps yet - if you have a proposal then feel free to open an issue in this repo for it!
@riverar this is unfortunately not in the plan for WinUI 3.0 RTM. There are challenges with supporting this in a UI platform that's decoupled from the OS, but we're planning to revisit this after 3.0.
@pnp0a03 the WinUI Xaml control is only supported in WinUI 3, but there is a developer preview of the core WebView 2 SDK for Windows 7, 8 and 8.1 for win32 apps: https://docs.microsoft.com/microsoft-edge/hosting/webview2
@GraniteStateHacker It's a bit too soon I think - WinUI 3 is still too new to have much ecosystem support (it's only in alpha) but @hassanuz is starting a workstream to investigate library compatibility/migration options.
No - you can use it in a variety of ways, for example:
@dwalleck WinUI 3 already has an alpha out and should have a more functional preview around the Build conference timeframe, and both are targeting late 2020. If you start with UWP Xaml and/or WinUI then you should be on a good path for 10X development.
@jschroedl Xaml element trees & brushes are retained-mode but you can use one or more of several options to include lighter-weight rendering primitives:
Great question! Paging @marb2000 to make sure this is covered and give the latest updates. In general the WinUI Xaml trees should use AutomationPeers but I'm not sure yet if that will extend any new functionality to non-WinUI win32 content.
The main printing functionality for WinUI content should be through a WinUI verison of the WinRT
WinUI isn't replacing hwnds but the goal is to abstract away their usage for common use cases by providing a Xaml API - sort of similar to how WPF works. The Xaml API will indeed still use hwnds/CoreWindows as an underlying implementation detail, and we'll likely have "backdoor"/"escape-hatch" APIs to get direct access to hwnds when needed. We should have a proposal draft in a few weeks which will make this clearer. |
|
@jesbis Thank you for your answer, but my concern was not solved unfortunately.
|
|
@jesbis Thanks for replying to my questions, although it felt demotivating. Trying to be constructive here. So the best that Microsoft can offer regarding C++/WinRT tooling is to point out to some up in the air proposals, that with luck might land on ISO somewhere between C++23 or C++26, if at all. And then wait for Visual Studio team to eventually rebuild C++/CX on top of them, which makes it about 6 years from now. If I want great C++ UI tooling, WinUI definitely isn't it, rather Qt or C++ Builder, with the added benefit of platform portability. So after watching the presentation, and still wearing scars from XNA (have rewrite in C++ with DirectXTK), WinRT 8.0, WinRT UAP 8.1, UWP W10, C++ Direct2D instead of System. Drawing (until Win2D came along, now stagnant), WinUI is definitely something that I will put on hold. Going forward I will advise my customers to go WPF when using .NET, Qt when using C++, or focus on PWAs if doable with Web technologies. WinUI 3.0 roadmap doesn't inspire any confidence that yet another reboot is around the corner, if selling UWP keeps failing on the desktop market. In a sense what I want to point out is that Microsoft management should think it through how to sell us the idea of adopting WinUI, after failing us so many times since Windows 8 release. |
|
@pjmlp general C++/WinRT feedback is probably best directed to the cppwinrt repo. ISO standard updates take time but I hope it'd be less than the timeframes you mentioned - reflection support is a top priority and they were just discussing it at the C++ conference in Prague last week. DirectXTK is still in development has been getting regular updates. In terms of Xaml framework APIs, WinUI is the path forward and has a fairly unbroken compatibility lineage back to Windows 8 - we spend a lot of time trying to maintain a high degree of compatibility 🙂 There are a few changes (due to shell integration, VS project structure, etc.) but for the most part you could likely port Windows 8 Xaml to a current Windows 10 app, recompile it and run it on the latest insider flight and it would work. Some of the high-level benefits of WinUI will include removing the barriers between UWP WinRT APIs and win32 APIs, supporting .NET 5, enabling immediate downlevel support for new features, removing the need to do many conditional OS version checks, enabling OSS contributions and enabling incremental updates to existing win32 apps using Xaml islands. |
|
@pnp0a03 there are efforts to bring .NET elements to market as well. I cannot give specific dates, but we are aware of the demand for this and are working out the details. @jschroedl we want to eliminate airspace issues, we are trying to work out a rendering plan that will help us achieve this. |
|
@jesbis As mentioned I don't believe complaining on cppwinrt will do anything, I rather complain by not adopting C++/WinRT unless for the use cases I am cannot avoid, specifically because the roadmap is to adopt feature that might not even be accepted into ISO. Regarding DirectXTK, I was giving yet another example on how Microsoft has forced us to rewrite our C# code into C++, with less capable tooling, by dropping XNA and providing DirectXTK as "alternative". Thankfully the open source community managed to come up with MonoGame and do the work Microsoft refused to pursue with XNA. I saw it during the presentation and in some of the comments here, how C++ is great and fun, how WinDev (once more since Longhorn's take over) keeps selling C++ first, .NET later. If I want great C++ tooling, Qt and C++ Builder are my environments of choice, not Visual C++. You really should ask mangement to allow your team to have a look at what is possible today in the competition, instead of expecting some metaclasses and reflection ideas to be accepted at ISO. No only do we have to bother with the APIs and third party libraries that won't carry over from .NET Framework into .NET Core, we also have to deal with all the migration issues from WPF/UWP into WinUI and the "just write it in C++/WinRT, it is cool and it is be better in a couple of years" mentality. Microsoft management really has to think it through, how to sell this rewrite to burned .NET developers, otherwise we won't move away from stacks that already do their job. |
|
@pjmlp Speaking of DirectX, I'm actively working on a portable and agnostic C# graphics, audio and input framework in my free time that will be capable of running D3D12/11 etc in a WinUI view.... among many other things. It supports a much more modern and performance focused approach of rendering vs something like XNA. Its not ready for use but is something many people have wanted including myself... so I'm making it. D3D12 and Vulkan will be the first targets supported. You will also be able to write shaders in C# instead of HLSL or GLSL etc. When its ready to use I will share more but because this is a framework and not some massive SDK or game-engine, it will be very portable and lightweight yet powerful and easy to use. Perfect to render 3D content in WinUI, WPF, or some native C# Win32 or WinRT app. |
|
@zezba9000 Thank you for the information, lots of impressive stuff you have done, kudos! I guess in what concerns managed support for DirectX we can only count on community efforts like yours, after tanking Managed DirectX and XNA, the C++ MS crowd took over DirectX development efforts. At very least any of these projects can count with my advocacy, as marketing to show others that it doesn't need to be only "C++ or the high road" as WinDev likes to push it. Here they could take a lesson from OpenGL ES/Metal with Swift, or OpenGL ES/Vulkan with Java/Kotlin. Apparently using managed languages for 3D programming wasn't an issue for mobile platforms to win over Windows (sadly, WP was a great experience). Good luck for your efforts, writing shaders in C# looks really appealing and I wasn't aware of CS2X. |
|
@pjmlp Ya the CS2X part is what will allow for writing agnostic GPU shaders in C# (which is cool because you will be able to Unit-Test your shaders in theory). For targets that can make use of a C# subset, CS2X allows me/others to target platforms outside what current .NET runtimes support with a very lightweight runtime as CS2X can compile C# subset to a C89 runtime... and because the Orbital-Framework can target the CS2X => C89 runtime, it in turn can target these platforms as well. Big project but its what I care about and I'm dedicated to making it happen. |
|
Is it going to be possible to use HwndHost with WinUI 2.4 |
Good luck with this! It's an insane amount of work! |
There's an issue open for a way to host user32/comctl or WPF UI inside WinUI XAML: #1833 It looks like it won't be made until after 3.0, if it is made. |
|
I post this to #1833
<#1833> but I ll copy
it here too: Right now we have WPF app that uses lot of c++ code through
HwndHost control. We are planing to move Wpf app to WinUI and moving Xaml
works great without problems, but what about HwndHost, is this going to be
possible with WinUI3. In our case we are doing interoperability with
DirectShow through HwndHost and right now in WinUI 2 , this is not
possible. What will be realistic date to use HwndHost in WinUI3? Also is
this new Xaml Window and Application like discussed at latest February
WinUI Community call, could help or not?
El dom., 23 de feb. de 2020 a la(s) 13:42, Max Strini (
notifications@github.com) escribió:
… Is it going to be possible to use HwndHost with WinUI 2.4
I tried at prerelease version and this didn't work.
Also is it going to be possible with WinUI3 with all this new planned
Windowing (XAML Window) and Application (XAML Application) and if yes when
we can expect first preview to see that.
Actually if it is going to be possible in WinUI3, will this functionality
be added to WinUI 2 new releases, or WinUI 2 will just work in Uwp apps.
For example right now, we have WPF app, that uses lot of C++ code through
HwndHost, and because we are planing to move everything to WinUI, this part
is very critical to us to decide to go with WinUI or something else.
There's an issue open for a way to host user32/comctl or WPF UI inside
WinUI XAML: #1833
<#1833>
It looks like it won't be made until after 3.0, if it is made.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1972?email_source=notifications&email_token=AG66BVVOQ6W3Z6LBVYZVJ63REJVLPA5CNFSM4KUFQ6MKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMV2ZRQ#issuecomment-590064838>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AG66BVRWNTNC7FUIBBP5C6DREJVLPANCNFSM4KUFQ6MA>
.
--
Mario Rancic
Software Engineer
Microsoft Certified Professional
|
|
Really good WinUI Community call last week! The content was very interesting and detailed/technical enough to provide a lot of insight. The roadmap/development status updates are also extremely valuable for consumers of WinUI and our own development roadmaps. I look forward to the next call! |
|
About HwndHost in WinUI 3. |
|
Well Uwp Camera looks better, but not sure can we use it in our scenario.
We are using camera as virtual camera with DirectShow and we need it show
video, to grab the camera stream for a photo and also with PjSip in the
same time, before we could just do it with DirectShow. Can we use this Uwp
MediaPlayer with PjSip.
El mié., 26 de feb. de 2020 a la(s) 23:47, Miguel Ramos (
notifications@github.com) escribió:
… *About HwndHost in WinUI 3.*
HwndHost allows to host Win32 content inside of WPF. Unfortunately there
is no plan in WinUI 3.0 to support this, including in WinUI 3.0 Desktop or
WinUI Islands. About the scenario @mariorancic01
<https://github.com/mariorancic01> described, did you evaluate UWP
MediaPlayer APIs instead of DirectShow?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1972?email_source=notifications&email_token=AG66BVR4ABZ7KA3S2RQVHELRE3WOJA5CNFSM4KUFQ6MKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENCGCSY#issuecomment-591683915>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AG66BVSBFMKZMD3TD5RGDKTRE3WOJANCNFSM4KUFQ6MA>
.
--
Mario Rancic
Software Engineer
Microsoft Certified Professional
|
|
I have question about Windows Store for Business, this looks very cool and very useful for LOB apps, but I read this might be abandoned. Can anybody say something about plans about this . |
|
@marionrancic01 It is not really necessary since you can now distribute UWP apps via MSIX packaging. |
|
sad, like @mariorancic01 also I find the Windows Store for Business useful 😞 |
|
@leoniDEV I am honestly curious why you would need Windows Store for Business, when you can simply publish as msix, as @kmgallahan said |
|
@kmgallahan @jtorjo I suppose what they are looking for is to have a private application catalog. MSIX does not offer that I believe? Unless you build a website where you list the MSIX your company provides, or use some management tool to deploy things to your users? |
|
Publishing to Windows Store is not a walk in the park - it's waay more complex than you think. First off, you need to wait for a certificate from MS - the one that you'll use to publish (I don't remember the exact steps right now). Then, you need to make sure your app doesn't violate any Store requirements. Then, any update you make can take days to be accepted (or it can be rejected), and you would rely on the store's algorithm for people to find your app. But if you deploy yourself, it will be a bit hard to set it up (I would know), but once that is done, it will be easy peasy. But yeah, you'll be in charge of showing your app to the world. |
|
As someone who has multiple apps on the Microsoft Store, including the store for business I can tell you that publishing to the Microsoft store has gotten much better in the past few months. Certification for regular updates sometimes happens as fast a few hours. The store guidelines are also pretty easy to meet. |
|
@jtorjo You do not need any certs. |
|
To be clear, there are issues with the store and the developer dashboard does go down from time to time, but my point above was that it is pretty convenient to have the store for business apps. |
@yaichenbaum That's definitely good to know. When I was publishing (2 years ago or so), it was waay harder. Yes, you do need to sign it on your own - in fact, you buy a certificate, and sign it as part of the "Publish" process. So once you've set it up, you can forget about it. @riverar When I was publishing (2 years ago or so), I remember you need to reserve a name, and then you need to wait for something that MS will use to sign your app (which is what I meant, by a certificate -> one that MS will issue for you). |
and others
Update: thanks everyone who was able to watch live and talk with us, or watch the recording!
Hi all -
The next WinUI Community Call will be on Wednesday Feb 19.
We'll be broadcasting live on the Windows Developer YouTube channel again:
https://www.youtube.com/watch?v=tasbSc3771A
Details
Date: Wednesday February 19
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'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!
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
We'll also have a few dev team leads on the call this month to help comment or answer questions.
The text was updated successfully, but these errors were encountered: