microsoft-ui-xaml 🚀 - 👩‍💻📞 WinUI Community Call (Febuary 19, 2020)

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?

jp-weber on 14 Feb 2020

👍3

AMD Ryzen support is preventing me from running the Emulator, so any word on when that will be rectified will be good to hear.

mdtauk on 14 Feb 2020

👍3

@jp-weber @mdtauk

This is the official wording (https://docs.microsoft.com/en-us/dual-screen/windows/get-dev-tools):

AMD processors are not supported at this time. Nested virtualization is required to run Windows 10X in the emulator and Windows does not yet support this on AMD processors. Stay tuned!

If you want more info you should probably contact [email protected]. I doubt WinUI is the correct team to ask Emulator specific questions.

Felix-Dev on 14 Feb 2020

👍4

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.

jesbis on 14 Feb 2020

👍3

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 on 15 Feb 2020

@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.

Felix-Dev on 15 Feb 2020

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..

infoequipt on 15 Feb 2020

👍1

@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.

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 on 15 Feb 2020

@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 How Windows 10X runs UWP and Win32 apps and desktop bridge test apps. Unfortunately, my XAML Island test apps fail to load on the emulator currently (stuck at the App Launch Initialized stage) so I cannot check which container they will use. I would be surprised if it isn't the Win32 container though since they are still Win32 apps. All that leads me to believe thatWinUI Desktop apps will run in the Win32 container on 10X.

It's certainly a good question to ask the team!

Felix-Dev on 15 Feb 2020

@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.

leoniDEV on 16 Feb 2020

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.

Gavin-Williams on 16 Feb 2020

👍7

@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 Windows AppConsult Engineer). A MS employee in the UWP Community said that support for UWP apps running a Win32 full-trust process won't be supported one day 1 but is planned to be added later.

@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 CoreWindow) too. These types of apps don't have to deal with the UWP sandbox or other design restrictions of the UWP. As they are no UWP apps, however, your WinUI Desktop app won't be able to target the broad range of Windows 10 device categories an UWP app can.
See the image below taken from the WinUI roadmap for a good overview:
alt text

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 believe they will run in the mentioned Win32 container is purely based on my current understanding of WinUI Desktop, the 10X video and desktop bridge test apps I ran on 10X. I have no insider knowledge. The WinUI team will surely let us know what is the plan with WinUI Desktop apps and the 10X container used and I'm happy to be corrected here and be told that yes, WinUI Desktop apps will run in the UWP container on 10X.

Felix-Dev on 16 Feb 2020

👍1

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?

robertsundstrom on 16 Feb 2020

👍2

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.
Kenny Kerr, the creator of C++/WinRT, is working on a new Rust WinRT projection now.

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.

contextfree on 16 Feb 2020

👍2

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.

Gavin-Williams on 17 Feb 2020

👍3

For now UWP and it's successor WinUI is not ready for LOB applications

There are several problems we are facing

Poor performance. For example WinUI dependency property is 50 times slower than https://github.com/microsoft/microsoft-ui-xaml/issues/1633 .
Poor compilation performance. Several times slower than wpf
dotnet native
A lot of breaking changes between releases.
Sandboxing and permissions model
Limited customization ability for 3d party vendors compared to wpf

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 )

Xarlot on 17 Feb 2020

👍7

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.

pjmlp on 17 Feb 2020

👍6

When will Windows 10X UI elements make their way to desktop Windows 10?

carmellolb on 17 Feb 2020

@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 ;)

Gavin-Williams on 17 Feb 2020

😄2

@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.

Gavin-Williams on 18 Feb 2020

👍2

About the call: why did you move away from Teams? YouTube didn't work out so well on the last one.

myokeeh on 18 Feb 2020

@Gavin-Williams

From https://github.com/microsoft/microsoft-ui-xaml/issues/1215#issuecomment-531994216:

Our approach is that WinUI 3 will use CoreWindow when running in UWP and Win32 Window(HWind) when running in Desktop (Win32).

WinUI 3 in UWP apps will be able to use AppWindow APIs. For Desktop, there will be needed to come out with something similar. We are still designing this, so I don't have more details so far.

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 https://github.com/microsoft/microsoft-ui-xaml/issues/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:

For Desktop Bridge apps, just send toast notifications like a UWP app would. When the user clicks on your toast, your app will be command line launched with the launch args that you specified in the toast.

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 on 18 Feb 2020

👍1

@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

Required components

The project and source code for your app. Using the WindowsXamlHost control to host standard first-party UWP controls is supported in apps that target the .NET Framework or .NET Core 3.

A UWP app project that defines a root Application class that derives from XamlApplication. Your WPF or Windows Forms project must have access to an instance of the Microsoft.Toolkit.Win32.UI.XamlHost.XamlApplication class provided by the Windows Community Toolkit. This object acts as a root metadata provider for loading metadata for custom UWP XAML types in assemblies in the current directory of your application.
Although this component isn't required for trivial XAML Island scenarios such as hosting a
first-party UWP control, your app needs this XamlApplication object to support the full
range of XAML Island scenarios, including hosting custom UWP controls.
Therefore, we recommend that you always define a XamlApplication object in any solution
in which you are using XAML Islands.

leoniDEV on 18 Feb 2020

I struggled for many, many hours to get C++/WinRT working, and failed to do what I did in 30 minutes with C++/CX

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.

@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).

jesbis on 18 Feb 2020

About the call: why did you move away from Teams? YouTube didn't work out so well on the last one.

If you mean the audio issues: we think we had a bad cable last month and are hoping it should be better tomorrow. YouTube seemed to be more accessible for most people, and the Channel9 studio has way better audio and video than the conference room we were using for Teams.

RE: CoreWindow, win32 support, containers - we'll talk about our current direction during the community call tomorrow with @marb2000 :)

We'll also try to get to the other questions so far (e.g. current status on SwapChainPanel timeline, Win2D/DirectX, islands, etc.) - thanks for the comments & questions so far!

jesbis on 18 Feb 2020

👍1

@jesbis Thanks for getting back to us.

There are no issues to open, because C++/WinRT approach to development is completely backwards to the productivity offered by C++/CX.

With C++/CX I initially thought that Microsoft was finally selling Visual C++ the right way, 25 years later Visual C++ had caught on with the RAD experience of C++ Builder.

Instead what C++/WinRT gives me is a return to the ATL/WTL days, where I have to write MIDL boilerplate, even though MIDL 3.0 is somehow nicer that the original MIDL, have to manually write UWP bindings boilerplate that C++/CX handles for me.

Not that C++/CX is perfect, the way it handles event handlers still fails short of C#/VB.NET, or C++ Builder for that matter.

UWP is anyway tied to Windows, so having a pure C++ binding is not something that buys me into C++/Winrt, rather being able to do exactly the same as in C# or VB.NET, without having to deal with code that still feels like ATL/WTL.

And as mentioned, I am only busy with C++ because the appeals to expose DirectX as a set of UWP Runtime Components keeps being ignored.

So I don't feel opening issues on cppwinrt will improve the ability to use C++/Winrt across Blend and Visual Studio as easy as C++/CX, ideally as easy as C# and VB.NET, as I expect the cppwinrt team to shift the problem into the Visual Studio team, and traditionally (MFC/ATL/WTL) the C++ tooling team never cared to provide the same high level tooling as the .NET languages enjoy, even though other companies are able to do so with C++ (Qt, Embarcadero).

pjmlp on 18 Feb 2020

👍4

@pjmlp thanks for the details - I'm checking with some people to see if there's any more info to share on C++/WinRT tooling, although I probably won't have good answers by tomorrow. We're focused on C++/WinRT for new development, but we do have it on our roadmap to hopefully have C++/CX templates for WinUI 3 as well if that helps.

jesbis on 18 Feb 2020

👍1

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..

@infoequipt could you elaborate on what you mean by isolation? E.g. like AppContainer support?

jesbis on 18 Feb 2020

For now UWP and it's successor WinUI is not ready for LOB applications

A lot of breaking changes between releases.

@Xarlot what breaking changes were causing problems for you? With UWP APIs we try to maintain a high degree of compatibility every release.

jesbis on 18 Feb 2020

@Gavin-Williams Regarding SharpDX being deprecated, you might want to look into Vortice.Windows, which is a great alternative for it. @Aminator is currently using it in his own fully UWP/C#/XAML DX12 game engine and editor, DX12GameEngine.
Hopefully that suits your needs in your apps! 😄

Regarding questions for the call, I have one which is a minor detail, but while we're at it: could we use the switch to WinUI 3 to also fix some small legacy UI bugs that could be considered "breaking changes", like the StackPanel applying the Spacing property incorrectly to collapsed items?

Ie. if you have some collapsed items in a StackPanel, it will still apply the spacing between them, forcing you to fallback to manual padding/margin between items if you have some of your items that can be shown/hidden programmatically. I've fixed this specific bug in a PR for the WrapPanel in the Windows Community Toolkit (#2838), and apparently this behavior in the StackPanel was a known issue recognized by some other MS engineers as well. 🤔

Keep up the great work! 🚀

Sergio0694 on 18 Feb 2020

👍3

@leoniDEV Thanks for pointing this out. Let's see if we will get some definite answers tomorrow 🙂

@jesbis Two more questions regarding WinUI Desktop (related to each other):

Will WinUI Desktop apps have an in-built switch between multi-instance (Win32 standard) and single-instance (UWP standard)? Right now if we want a Win32 app to be single-instance we have to implement this behavior ourselves. This might not just require an app lock (like a mutex to check if an instance is already running) but also Win32 API like SendMessage to pass operations from a second app instance to the primary app instance (see question 2). It would be great if we could get the option to have the single-instance behavior of UWP apps for WinUI Desktop apps.

Will WinUI Desktop apps be able to use the UWP Jumplist API? Currently, desktop bridge apps cannot effectively use them because the app seemingly can't be activated (see Windows Terminal issue https://github.com/microsoft/terminal/issues/576 for a brief overview of the problems). I would like full support of this API for WinUI Desktop apps because they are much easier to work with than the Win32/WPF APIs. For example, jumplist task icons can be easily set using the ms-appx:/// or ms-appdata:/// URI schemes instead of having to create an .exe or .dll containing the images, then set the path to that binary file and also an offset into the file for the specific icon.

The docs sum up the advantages of the UWP Jumplist API:

Alternatively, use the UWP Windows.UI.StartScreen.JumpList APIs instead, which allow you to reference string and image assets using the package-relative ms-resource URI scheme (which is also language, DPI, and high contrast aware).

The single-instance behavior of UWP apps also potentially makes working with jumplists much easier. If you have a jumplist task which should operate on the current running app instance, in WPF/Win32, a second app instance is launched which then needs to use, for example, the SendMessage Win32 API to send the requested operation to the primary app instance. Using single-instance behavior on UWP the running app easily gets the invoked jump task. without all the additional work in the Win32 case.

Felix-Dev on 18 Feb 2020

@pjmlp another thing that might be of interest if you haven't seen it is this session by Kenny Kerr and Scott Jones from the last Build conference, particularly the last ~11 minutes where they talk about some prototyped improvements to bindings, and some C++ tech specifications for adding reflection and metaclass support that could completely remove the current IDL & metadata codegen requirements:

https://youtu.be/X41j_gzSwOY?t=2659

If we have time then we can talk about this a bit in the call tomorrow too.

jesbis on 18 Feb 2020

👍1

Thanks @jesbis, I am aware of that talk. It is still too far in the future as I can tell.

Right now it looks more likely that I will port my existing DirectX code to something like the Vortice library, pointed out by @Sergio0694 than wait for such tooling to bare fruits.

I do admire your efforts, but here from the trenches, after Silverlight, XNA, WinRT, UAP, UWP, WinUI, .NET Framework, WCF, EF6, eventually we get tired to keep doing rewrites.

WinUI should be better than WPF in all senses, and if we are forced to use C++ because reasons, then its tooling should be at the same level that .NET developers have come to love, to actually be worth to move beyond WPF or making a point to avoid business wanting to go with Electron style apps.

pjmlp on 18 Feb 2020

👍1

As @Sergio0694 already asked, will WinUi 3.0 be used not only to switch namespaces but also contain other breaking changes, that are needed to fix bugs such as incorrectly applied spaces?

If so would there be a chance to rename the NavigationView.IsBackButtonVisible property to BackButtonVisibility as the name and type currently do not really line up (IsBackButtonVisible is an NavigationViewBackButtonVisible enum, not a bool). This was also discussed here.

chingucoding on 19 Feb 2020

👍2

@chingucoding I recall the team said that for WinUI 3.0 itself breaking changes should be minimal to make porting existing (UWP) apps to it as straightforward as possible. I suspect these changes, if approved, will be implemented in subsequent WinUI 3.x/4/5/.... releases.

Felix-Dev on 19 Feb 2020

👍2 👀1

Q: Will WinUI 3.x support AcrylicBrush with HostBackdrop? It's currently known broken in the alpha but am curious if it's on the roadmap to be fixed before release.

Q: Will WinUI Desktop enable desktop app devs to _finally_ use AcrylicBrush with HostBackdrop? We previously used composition attribute WCA_ACCENT_POLICY with ACCENT_ENABLE_ACRYLICBLURBEHIND but Microsoft critically broke this in 19H1+ and our app has been suffering since. (It also affected things like the Emoji Picker but Microsoft serviced those components to use non-acrylic method instead.)

riverar on 19 Feb 2020

About WebView2:
https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2

"Developer preview is available for Win32 C++ on Windows 10, Windows 8.1, Windows 8, and Windows 7. In the future, we plan to support WebView2 on .NET, and XAML."

My question is .. Is it planned that the .NET Version of WebView2 SDK that applicable for Win8.1, 8 and 7?
I have a concern that parhaps WebView2 on .NET is supported only via WinUI3. In my understanding, WinUI3 WinForms app support is only applicable for .NET Core based and only for Win10.
Let me explain the my situation.. My client have many of WinForm desktop apps that use the IE BrowserControl. But IE is obsolte and want to migrate to modern browsers. And, these app SHOULD support the Win7, 8, 8.1. (don't blame me for old os support)

pnp0a03 on 19 Feb 2020

If possible:

Win32 ETA on a preview build for WinUI 3.0

If source code is not ready to share, maybe giving out a already complied demo exe of some UI elements running we could download and play with would be cool to show off to fellow co-workers.
Does WinUI 3.0 support custom shader effects like WPF/Silverlight did? If not are there any thoughts on adding them later? Is the rendering layer used by WinUI even capable of this?

zezba9000 on 19 Feb 2020

👍3

@leoniDEV I went ahead and created a XAML Island project as you highlighted (so no separate UWP project). It contains a single UWP inbox control (a button) and works fine on 10X. No surprise for the container story...it runs in the Win32 container as expected.

So it seems that at least right now there is not yet full support for XAML Island apps consuming a separate UWP project.

Felix-Dev on 19 Feb 2020

I'm looking at doing v-next of a legacy WPF app. I can probably use .NET Core WPF, but I really want to use WinUI. I'm running into issues with libs like Prism still deriving from Windows.UI.Xaml (as opposed to Microsoft.UI.Xaml). It feels like these types of issues are foundational. Is there solid PnP guidance for WinUI, yet, or is it too soon?

GraniteStateHacker on 19 Feb 2020

Is it possible to get someone from the shell team or inbox apps team on to talk about why the start menu and file explorer on Windows 10x are web-based instead of using WinUI?

matthew4850 on 19 Feb 2020

👍6

All I need is a seamless porting experience from our current UWP app (with desktop extension) to a WinUI Desktop app (without the desktop extension). Will this be possible? What are the pitfalls in this scenario?

If this proves to be difficult, will it be possible in the future to improve UWP (for apps running on the desktop) to always run apps in the background and allow them to call all win32 API's through P/Invoke and allow for dll's that load other dll's without LoadPackagedLibrary (but with LoadLibrary).

wbokkers on 19 Feb 2020

👍3

How likely is it that WinUI 3.0 will be ready to launch when the first Windows 10X devices launch? I'm interested in jumping into the Windows dev world and I'm trying to decide what approach makes the most sense at this point.

dwalleck on 19 Feb 2020

Thanks everyone for the questions and for watching if you could make it! The recording is live at the same link.

There were lots of questions we didn't get to - I'll try to summarize them and post some responses here soon.

jesbis on 19 Feb 2020

👍4 ❤1

Good show guys, thanks for taking my question and for Miguel presenting.

infoequipt on 19 Feb 2020

❤3 👍1

I'll add a few more questions I'm left with in hopes that they'll be addressed.

Traditional Win32 apps draw to the screen in WM_PAINT. XAML apps are retained mode. We draw WAY too many things to the screen to create individual objects/controls. Will there still be a WM_PAINT equivalent to allow me to draw to the window but with more modern API? Win2D or some other immediate-mode API?
Accessibility is handled differently in Win32 (COM APIs) vs, say, WPF (Automation Peers). If I write a Win32 + WinUI application, will I be able to augment or control the accessibility tree any easier? Or will I stick with the old COM APIs? How would I blend my custom drawn content with accessible controls in the accessibility tree?
Today, we print by drawing into a printer DC. Is there a new printing with Win32+WinUI?
I'm still a bit baffled with regard to the relationship between a HWND, a CoreWindow and whatever comes next for WinUI. Will HWNDs still exist or will we be replacing CreateWindow calls with something else? I assume so... but if that's the case I assume there must still be an underlying HWND for cases where we must hand one off to external components (parent HWND for example).
Will WebView2 use in a Win32+WinUI app have the airspace issues we encounter with the embedded IE control?

jschroedl on 19 Feb 2020

👍2

Starting to catch up on some questions:

Is WinUI just UWP development but a more modern spec? I see conversations about WinUI and I'm not 100% sure if they are talking about UWP dev, particular libs in UWP dev or something different entirely

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 Windows.UI.Xaml, Windows.UI.Composition and parts of Windows.UI.Input.

Will WinUI apps have an in-built switch between multi-instance (Win32 standard) and single-instance (UWP standard)?

@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!

Will WinUI 3.x support AcrylicBrush with HostBackdrop? It's currently known broken in the alpha but am curious if it's on the roadmap to be fixed before release. Will WinUI Desktop enable desktop app devs to finally use AcrylicBrush with HostBackdrop?

@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.

About WebView2: My question is .. Is it planned that the .NET Version of WebView2 SDK that applicable for Win8.1, 8 and 7?
I have a concern that parhaps WebView2 on .NET is supported only via WinUI3.

@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

I'm running into issues with libs like Prism still deriving from Windows.UI.Xaml (as opposed to Microsoft.UI.Xaml). It feels like these types of issues are foundational. Is there solid PnP guidance for WinUI, yet, or is it too soon?

@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.

Is WinUI only for Store apps?

No - you can use it in a variety of ways, for example:

include it in an existing win32 app (WPF, WinForms, MFC, etc.) using Xaml Islands
build an MSIX installer and deploy however you'd like
create an unpackaged app and distribute it via xcopy or other means (not supported for WinUI 3 yet but planned for RTM)

How likely is it that WinUI 3.0 will be ready to launch when the first Windows 10X devices launch? I'm interested in jumping into the Windows dev world and I'm trying to decide what approach makes the most sense at this point.

@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.

Traditional Win32 apps draw to the screen in WM_PAINT. XAML apps are retained mode. We draw WAY too many things to the screen to create individual objects/controls. Will there still be a WM_PAINT equivalent to allow me to draw to the window but with more modern API? Win2D or some other immediate-mode API?

@jschroedl Xaml element trees & brushes are retained-mode but you can use one or more of several options to include lighter-weight rendering primitives:

composition layer Visuals
composition layer Shapes which enable drawing very high-performance retained geometries - also used for things like the WinUI AnimatedVisualPlayer control which can play Lottie shapes/animation
DirectX interop with Xaml using SwapChainPanel, SurfaceImageSource or VirtualSurfaceImageSource (depending on whether you want a swap chain or virtualized/non-virtualized brush model)
Win2D, which abstracts the above DirectX interop for you (with Direct2D, DirectWrite) and provides a .NET API

Accessibility is handled differently in Win32 (COM APIs) vs, say, WPF (Automation Peers). If I write a Win32 + WinUI application, will I be able to augment or control the accessibility tree any easier? Or will I stick with the old COM APIs? How would I blend my custom drawn content with accessible controls in the accessibility tree?

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.

Today, we print by drawing into a printer DC. Is there a new printing with Win32+WinUI?

The main printing functionality for WinUI content should be through a WinUI verison of the WinRT PrintDocument API.

I'm still a bit baffled with regard to the relationship between a HWND, a CoreWindow and whatever comes next for WinUI. Will HWNDs still exist or will we be replacing CreateWindow calls with something else? I assume so... but if that's the case I assume there must still be an underlying HWND for cases where we must hand one off to external components (parent HWND for example

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 on 19 Feb 2020

👍2

@jesbis Thank you for your answer, but my concern was not solved unfortunately.
Currently, WebView2 SDK Win32 "C++" (preview) version is released from this site. It supports Win7, 8 and 8.1.
https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2
My question is about .NET version. Currently, .NET version is only supported by WinUI 3, But, as you know, we can't use WinUI 3 on Win7, 8, and 8.1 ( is this right? ).
Thus, I've post my question as below.

My question is .. Is it planned that the .NET Version of WebView2 SDK that applicable for Win8.1, 8 and 7?

pnp0a03 on 19 Feb 2020

@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 on 19 Feb 2020

👀3 👍3 👎2

@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.

jesbis on 19 Feb 2020

@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.

adambarlow on 19 Feb 2020

@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 on 20 Feb 2020

👍2 😕1

@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.

https://github.com/reignstudios/Orbital-Framework

zezba9000 on 20 Feb 2020

👍4 ❤3

@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 on 21 Feb 2020

@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.

zezba9000 on 21 Feb 2020

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. Also even WinUI 2 looks good for us, XAML part is so easy to transfer, Composition Api work great, Uwp Community Toolkit works great, only we can't use HwndHost and c++ Win32 code. So is and when WinUI3 is going to solve this? Also I like a lot x:Bind but this is even at risk for WinUI3 release.

mariorancic01 on 21 Feb 2020

@zezba9000

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.

Good luck with this! It's an insane amount of work!

jtorjo on 22 Feb 2020

😄1

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: https://github.com/microsoft/microsoft-ui-xaml/issues/1833

It looks like it won't be made until after 3.0, if it is made.

contextfree on 23 Feb 2020

I post this to #1833
https://github.com/microsoft/microsoft-ui-xaml/issues/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 (
[email protected]) 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
https://github.com/microsoft/microsoft-ui-xaml/issues/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
https://github.com/microsoft/microsoft-ui-xaml/issues/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

mariorancic01 on 24 Feb 2020

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!

robloo on 25 Feb 2020

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 described, did you evaluate UWP MediaPlayer APIs instead of DirectShow?

marb2000 on 26 Feb 2020

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 (
[email protected]) 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
https://github.com/microsoft/microsoft-ui-xaml/issues/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

mariorancic01 on 27 Feb 2020

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 .

mariorancic01 on 16 Mar 2020

@marionrancic01 It is not really necessary since you can now distribute UWP apps via MSIX packaging.

kmgallahan on 16 Mar 2020

sad, like @mariorancic01 also I find the Windows Store for Business useful 😞

leoniDEV on 18 Mar 2020

@leoniDEV I am honestly curious why you would need Windows Store for Business, when you can simply publish as msix, as @kmgallahan said

jtorjo on 18 Mar 2020

@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?
In a similar way, the old MSI installers do not provide a way to discover apps as well.

hansmbakker on 18 Mar 2020

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.

jtorjo on 18 Mar 2020

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.
On the other hand, disturbing a standalone msix can be complicated. Unlike the store which signs packages for you, if you distribute your app outside the store, you need to sign it on your own.

yaichenbaum on 18 Mar 2020

👍2

@jtorjo You do not need any certs.

riverar on 18 Mar 2020

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 on 18 Mar 2020

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.

@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).

jtorjo on 18 Mar 2020

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

https://www.youtube.com/watch?v=tasbSc3771A

Details

Please leave questions/topics/feedback!

Agenda

Most helpful comment

All 72 comments

Related issues