These are my initial thoughts on the questions you asked in the issue content.

I come from a design and user perspective, with only a little development experience, who got very interested in Silverlight/Windows Phone 7 development back in the day who now feels a little burned.

What templates would interest you most?

I think before asking for a list of template ideas, there needs to be some kind of audit done of the biggest and most used apps in each framework, so WPF, UWP, WinForms, MFC etc.

Examine the "silhouette" of these apps and figure out the common UX scenarios.

Off the top of my head, there is:

• Main Menu (All frameworks)
• MDI (multiple documents in a single window) (MFC mostly)
• Tabs and Datagrid (WPF, WinForms, MFC)
• Ribbon (Win32 apps Office, 3ds max, paint, wordpad, File Explorer etc)
• System Tray Utilities (MFC, WinForms)
• Browsers
• Wizards (WPF, MFC)
• Complex MDI apps (Adobe software, Visual Studio)
• Media Players
• Data Visualisation LoB (WPF and Web)
• Social apps (React Native, PWA - Skype, Facebook, Twitter)

All or some of these could benefit from WinRT/UWP system integration with Notifications/Action Centre.

All these New Project templates should eschew the built in Windows.Xaml namespaces, WPF control theme, and WinForms visual styles in favour of new templates and visual styles which match the FabricWeb/Fluent control designs.

There should also be an easy way for devs with existing WPF and WinForms apps to add a WinUI 3.0 dependency which gives them the new control designs with a simple using statement or manifest entry

XAML Islands

As Xaml Islands becomes easier to make possible - replacing old webview controls, colour pickers, XAML based Dialogs could be as easy as a Add New... and choose a Dialog, or standard control which existing C# and C++ code can call into, and they have their own codebehind.

Modern app and page templates like Xbox Next apps, NavigationView, Master/Details, Hubs, Modern Ribbon, NavigationViewTop, and Pivot - could all be made available for all Windows Presentation Platforms - with XAML Islands in place and sample content.

Any of these scenarios which are not currently possible in UWP XAML, should be with controls and templates to make these easier.

Would it help if Visual Studio or another tool automatically updated namespaces for you?

It should be a question asked when someone opens their project on the latest version of Visual Studio with a current Windows 10 SDK. Press the button and it either replaces the name spaces and using, or flags them if it is not a control it is familiar with.

On new projects it should be the default, and the nuget package installed along with future versions of the Windows SDK.

What would be your preferred solution for using UWP components with WinUI 3?

As with the automatic updating answer, New pages and projects should include it by default, and a message asking if they want to Automatically move to WinUI | Add ToDo comments to update namespaces | Do not move to WinUI.

What kind of apps would you be most excited to use WinUI 3.0 for?

As a user I want all apps running on Windows to share a common UI and UX no matter what framework was used.

I want apps to be installed without messing with the registry and leaving junk behind. (so Centennial)

I want all the apps to be installable from within the store, or from a Centennial type installer. Virtualise the System and Windows folders for every app.

Modernizing a C++ MFC app with Fluent UI?

Acrylic should be available to WPF, WinForms, and MFC apps, and included in default new templates via a WinUI 3.0 dependency or manifest. CommonControls and window styles should use Acrylic and extended titlebars (which can be overridden to go back to the current defaults)

Microsoft's Win32 non UWP apps need to all be recompiled with WinUI 3.0 so they all use Acrylic window frames, main menus, ThemeShadows, Context Menus, Text Fields, Progress Bars etc.

And then existing apps need a simple solution to drop in WinUI 3.0+ which then updates the looks of all the controls - or the ability to apply it selectively one dialog at a time, until the entire UI is updated.

re: namespaces, I would expect them to just change based on the target even it requires conditional namespaces.

Here are my answers:

Creating a new app

What templates would interest you most?

• I'd love to see c++/winRT win32+xaml and .net core+xaml first there, UWP templates coming second, packaged win32 app should not come as a template, as current app package templates should just work as they already do with current win32/.Net apps.
• Additionaly, I'd love to see item templates like "New XAML Window" with boiler-plate code to show it in an existing win32 or .net core App application (e.g.: making existing systray app à la Docker Desktop, able to show a new top level Xaml Window)

Adding WinUI 3.0 to existing Win32 apps

• non-backward compatibility is the exact reason why I never used xaml islands on a real project (used it for fun on personal stuff though). Decoupling the UI framework from the Windows API is one of the greatest thing announced with the WinUI 3.0 roadmap (alongside the ability for non-packaged/non-uwp targetting apps to leverage it)

Updating your existing UWP Xaml app to WinUI 3.0

It might sound harsh, but I feel like UWP xaml app are a niche (since the drop of windows phone, there is no more traction toward UWP as a target platform), and even if tooling/interop would be nice to have, I don't think it should be the main focus for WinUI 3.0.
So both namespace update tooling (which might be actually done using a global find and replace) and mixing UWP xaml and WinUI xaml do not feel critical to me.

Also, just want to mention that this is a very welcome move, and having the whole UI framework open source on Github is awesome! Thanks a lot for doing this!

First of all, this is a great move! Unfortunately I cannot neglect the fact that I feel a bit hurt by the way Microsoft has dealt with the few last developers on their platform. At the moment I only use UWP for consumer-facing apps because:

1. WPF is way more mature than WinUI (validation, existing controls, etc), so for enterprise WPF is a better fit
2. UWP is great for multiple device categories (mobile, tablet, desktop, etc), that's where the consumers are at

It's great to see point 1 could be tackled with WinUI, so that makes me enthusiastic about the progress for WinUI. Unfortunately 2 is no longer applicable (no more cool devices, just desktops). It makes one wonder, at the time this stuff ships (1 year from now earliest?), what would developers need at that stage.

I think the consumer stuff is no longer part of the equation, that ship has sailed with the retrenchment "strategy". So the only thing it could be good for are enterprise apps.

In general, I would be more interested in a good migration strategy from WPF to WinUI to try and migrate our massive WPF code-base to Windows 10. The downside of having to update consumer-facing apps (currently UWP) is that they highly depend on external component developers (e.g. win toolkit, etc). I think there is no viable option to update these anymore since most developers (I know of) lost interest in consumer / windows client development.

Answers to the questions

Creating a new app

What templates would interest you most?

I would love to see .net core / xaml / C# here, since I think that's the most used language combination available. But maybe a migration template would be better here (try to get everyone on board as quickly as possible, the longer it takes, the more painful it will get).

Adding WinUI 3.0 to existing Win32 apps

I think this is extremely nice, and we would use this a lot (but realistically, this is at least a year away since enterprise customers are still on Windows 7, even when MS support ends, companies will be on Windows 7). Then we can slowly migrate WPF to WinUI 3.

Were you aware of Xaml Islands for modernizing desktop apps?

Yes, but too many customers are (or were) on Windows 7, so it was not an option for enterprise devs. And for consumers you could just use UWP anyway.

Does this expanded backward-compatibility on Windows 10 make Xaml Islands more useful to you?

It's a good start because at the time this stuff ships, it would work on all supported versions of Windows 10 in the enterprise.

Updating your existing UWP Xaml app to WinUI 3.0

Consumer apps for MS are over, all because of the choices MS made, there is no more room for this. I would just skip this whole option and forget about it. It's sad because I put thousands of hours into UWP apps, but I think we need to make this death quick to make it less painful.

The whole promised story was always up-to-date, support all devices. I think we all know what way that promise went.

Would it help if Visual Studio or another tool automatically updated namespaces for you?

If it's just namespaces, a search / replace should do the trick as well.

How important to you is full compatibility between existing UWP Xaml components and WinUI 3.0 apps?

No longer important, I am willing to take the loss of thousands of hours of development, there are no users left anyway.

Do you create or use UWP Xaml control libraries or WinRT components that you couldn't easily recompile and update alongside app code?

Nope.

What would be your preferred solution for using UWP components with WinUI 3?

UWP Islands (sort of hosted components)

General

What do you think about the overall 3.0 plan outlined above and in the roadmap? Would it enable you to use WinUI for your new and existing Windows apps?

It probably needs some maturing, but I see myself using this stuff in 1 - 2 years for enterprise development. Depending on how hard it is to migrate, we will either choose WinUI or web (depending on how Windows itself "evolves").

What kind of apps would you be most excited to use WinUI 3.0 for? Creating a new Win32 app and packaging it with MSIX? Adding new views to a WPF app? Modernizing a C++ MFC app with Fluent UI?

Probably just adding new views to a WPF app and slowly start migrating.

I very much like this roadmap. UWP needs to be freed from its shackles, and this is a great way to do just that.

Updating your existing UWP Xaml app to WinUI 3.0

This is very important for my employer. We have a complex UWP desktop app in the store. We now need Desktop Bridge to get access to win32 APIs that are not supported by .NET Native.

I would like

• direct access to all win32 API's;
• using a plain old win32 execution model. I'm fine with some Desktop Bridge-like sandboxing (e.g. virtualization of the registry);
• to put our app in the store (msix) as it is now;
• to still use WNS (push notifications);
• a painless update experience from UWP to some new Xaml Desktop app type. I don't mind doing some manual labor. Maybe I prefer good documentation over tooling here.

How important to you is full compatibility between existing UWP Xaml components and WinUI 3.0 apps?

Existing styles should still work. I can live with some minor visual changes. But not with changes in behavior.

Do you create or use UWP Xaml control libraries or WinRT components that you couldn't easily recompile and update alongside app code?

No.

What would be your preferred solution for using UWP components with WinUI 3?

If they can't be recompiled (third party): Xaml Islands-like approach. Otherwise it should be possible to easily port them to WinUI 3.

General

What kind of apps would you be most excited to use WinUI 3.0 for? Creating a new Win32 app and packaging it with MSIX? Adding new views to a WPF app? Modernizing a C++ MFC app with Fluent UI?

• Desktop win32 apps, packaged with MSIX.
• Uno cross platform apps ;)

Please do not introduce new namespaces for stuff like _INotifyDataErrorInfo_ - it should be used in view models that are usually cross-platform and should not have dependency on WinUI. It should be defined where other stuff like this is located (i.e. _INotifyPropertyChanged_ or _INotifyCollectionChanged)_

I would just like to know if the ultimate goal is to create a cross-plat UI stack. Understanding it might not be completely understood how we get there. However, if that is the intent... it would be better to brand this without the Win references at the beginning of this effort. It will be less headaches in the long term if you did.

Would it be better to label as XamlUI or similar? The Microsoft.UI.* namespaces are fine, just brand the repo and such as XamlUI 3.0 or similar.

Thanks for reaching out. Look forward to what's to come in this space :smile:

To me, all the technical details are less important.
UWP, WPF or any Windows-only framework, as awesome as it would be, isn't going to be enough so long it doesn't run on every platform (at least Windows, Droid, iOS and web), and is friendly with any screen size.

TBH was disappointed me on last Build to discover the MS has no plans on making UWP or XAML cross-platform. Uno got no official recognition other than a speech. Even more frustrating, I'd say hurting, was to discover that MS is giving so much love to React Native and HTML/JS driven frameworks AGAIN (WinJS), while neglecting the liable .NET stack devs.
I'd want to see MS officially creating a cross-platform UI stack like Uno, and providing the right tooling, templates, and integrated support.

And BTW, I have been working with XF since its acquisition by MS, and wish it had an alternative, for following reasons: a. No web support, b. Very mobile biased, no love for desktops c. Its library hierarchy feels sloppy, definitely when compared to WPF/UWP control-library d. Is not using MS XAML.
Here's the feature request I posted on Microsoft Developer Community: .NET UI Standard.

Thanks y'all!

We need a XAML UI that also runs on the Web (Assembly). At least a subset of UWP.
Why not embrace UNO platform and make the web rendering using SkiaSharp?
Could be Silverlight 6, the web counterpart of WinUI

Quick replies for the questions

What templates would interest you most?

.NET core SDK-style projects, or some simplified MSVC project format.
The old project files are too complicated to edit manually, and there are tons of interaction issues between the old and new project system. We should totally drop the old project system for brand new projects.

Were you aware of Xaml Islands for modernizing desktop apps?

No. I'm rewriting my application with a full data model change, so there's no progressive migration.

Does this expanded backward-compatibility on Windows 10 make Xaml Islands more useful to you?

There are still many users on Windows 7 and Xaml Islands can't help.

How important to you is full compatibility between existing UWP Xaml components and WinUI 3.0 apps?

No. All my components are self-written, or from MUX and WCTK, so I can perform a quick manual migrate.

Would it help if Visual Studio or another tool automatically updated namespaces for you?

No so much, because my project is not big(~20 pages and ~10 custom controls for now).

What would be your preferred solution for using UWP components with WinUI 3?

I'd like there to be a version shipped with OS, to allow creating very tiny tools and shiping in KBs. The tool simply fails to run on lower OS, as the supposed user can immediately contact me (e. g. through some chatting software).

What kind of apps would you be most excited to use WinUI 3.0 for? Creating a new Win32 app and packaging it with MSIX? Adding new views to a WPF app? Modernizing a C++ MFC app with Fluent UI?

Creating a new Windows 10-only app and ship without the store.
Trusted signing is expensive for individual developers, and uploading to store isn't applicable for domain-specific, not long-term applications.

My personal look for the UI platform

Xaml toolchain

The xaml language is somehow not serious, and I'm facing many issues like "how should I represent this". WPF xaml and UWP xaml aren't fully compatible, so I need to remember their differences. Xaml are not fully compatible with .NET features, so I sometimes need to write some ugly tricks in my model, and a helper class.

Coming with x:Bind, things becomes even worse. The simple scenarios are easy to use, but it's very complicated to do things that's more than a property access. For example, it doesn't support method overloading, so I must compile to check which overload is chosen for this binding expression. I cannot even do a simple switch, or a "visible when some property is false" conversion, and a helper method is required. The documentation says nothing about these detailed scenarios, so I think there should be a position for xaml-language-design discussion, and make xaml a seriously designed language like C#.

The xaml editor are hard to use too. It's reasonable for designer to try execute some code to show the actual effects, but the text editor should just be aware of metadata. Opening an xaml file in source view is slow because it's activating the designer, and throwing some interaction exceptions for totally fine-to-run xaml, such as NullReferenceException and Cannot convert __ComObject to some type. It touches ProjectReference through built libraries, and results in complicated error even when a simple edit to non-public-api area in dependency library, typically the implementation of data model. So I think there should be a metadata and source code aware, fully Roslyn integrated xaml compiler. This would benefit a lot if Roslyn has a "custom code generating/lowering plugin" feature.

A better windowing model

It's regular for information-full, state-full application to use multi-window model instead of navigating model. Currently in UWP, creating new window using ApplicationView is painful because there are threading issues. The new AppWindow shares the UI thread, and I'm not sure about its UI performance.

Rewriting Visual Studio in WinUI at sometime future can prove it to be a mature UI system.

Data binding interfaces

We are very tired for creating models implementing INotifyPropertyChanged. I've written a custom MSBuild task to convert a xml into expanded property accessors, but it doesn't help when I want to do something custom in the setter when the property changes.

And there are threading issues. My data come totally from a background network server, so context capturing for await can't help me. In WPF and Binding, it's just as-is because Binding solves threading itself. When changing to x:Bind, I have to solve it inside event raiser, because x:Bind just operate on the calling thread. Things becomes even worse when I have multiple application views touching the same data, which means there is not global UI dispatcher available, and the only solution is capturing SynchronizationContext.Current at event registration. For collections, ItemsSource is not thread safe neither, and the same workaround is required.

There should definitely be a toolchain to solve the modeling, threading, and extending issues for mutable bindable models. And a generic built-in solution for bindable collection should provide a mechanism for "specified property of any child changed".

IObservableVector<T> is a fake generic type that can uses object only, INotifyCollectionChanged is non generic. Just implement it for built-in collection like ObservableCollection<T> is not enough, especially for complicated, ISupportIncrementalLoading/IItemsRangeInfo oriented scenarios. The platform should provide an default abstract implementation with best practices, allowing the user just implement an abstract data-filling method.

@shaggygi @weitzhandler @TonyHenrique

If there is to be a Cross Platform future for UWP/XamlUI3.0 abstracting the XAML syntax, from the Windows Renderer, and the rest of the Windows Runtime would be a way to handle it.

If there could be an almost plug-in mentality with the project, there could be an Android or iOS/AppKit Renderer, and an Android/iOS AppKit Shim to pass ART APIs into C# and VB, as well as the existing C++, C language support.
Xamarin could help here.

Microsoft does not need to be the ones working on those alt platform renderers.

But focusing on Windows for now... WinUI 3.0 could encompass Fabric Web / React Native / WPF / WinForms / MFC. PWAs will also be a first class citizen for app development, so there are cross platform stories for apps not made for Windows/.NET/UWP directly.

What is needed now, is to provide a story for C#/.NET/UWP devs to bring their apps and investments to the wider landscape of platforms.

My 2 cents: I'm a Xamarin.Forms dev, and (like many others) am interested in seeing all XAML dialects being merged into one that works everywhere, including the mobile space. Not sure how that would go down, but that's at least my wish on the matter.

WinUI 3.0 onwards perhaps - but there are too many WPF apps out there to expect them all to re-write and translate all that XAML. New WPF projects could use the more modern WinRT XAML dialect. You could introduce the equivalent of a DocType to XAML so different dialects could co exist in the same project.

Easier said than done of course.

@mdtauk I think that once the Xaml platform is actually made open-source, we will have a clearer understanding about what it relies on on the bottom of the stack (we already know that the main platform-specific dependencies are DirectX11, Direct2D and Windows Media Foundation, but who knows what part of the Windows SDK is used there), and how it is layered (so that we can have an actual feeling about the feasability of any porting).
Also we have yet to see under what kind of license the source code will be distributed. I am not sure if it has been decided yet.

Android uses Vulkan and I think supports OpenGL
iOS and macOS use Metal

As for the media codecs, it may be possible to make use of native C based APIs to substitute.

@simonferquel It will become clearer when the code is refactored and checked in. And it may require some iOS and Android experts to lead those efforts.

I think changing the namespace was a reasonable approach when winui was collection of controls. However, now that it basically replaces the platform, I think this is not justified anymore. This is already works in same way for WPF/Winforms, where code can be moved from .net Framework to .net core without changing the namespaces in code. The platform should automatically be able to load the winui versions of the necessary dlls when enabled. In this way, source and binary compatibility (I have successfully used .net framework libraries in .net core apps) can be preserved.

Just wanted to say thanks everyone for the comments so far! The WinUI team is looking carefully at all the responses and points.
We'll also likely split off some focused issues to talk about specific points that have come up (e.g. compatibility with existing UWP frameworks and components) once we've organized our thoughts.

I just want to say thank you to MS for listening more and giving .net developers awesome tools, but I can’t help but feel disappointed with UWP Xaml future after the build conference.
Reading this blog and many articles on the net you get the feeling that UWP is becoming exclusively “enterprise” and even that is debatable as many enterprises are becoming more OS agnostic allowing workers to use for example MacBook Pro’s.

Let me be clear that I am heavily invested in native UWP and Xamarin Forms (Android, iOS) and I luv the platform, but after MS announce native support for React, I’m about to jump ship.

I know I must make my UWP app more platform agnostic on the desktop therefor I was hoping that I can create a “hybrid app” with my current uwp app as the shell and incorporating more and more web front end technologies by using React in the mix. Something like the proposed “Sets” feature that I understand is now delayed because of higher priorities within Edge, would have been ideal for my current solution as it totally blurs the lines between native UWP and web technologies by running native as well as web technology in “windows/edge tabs”. This “hybrid” approach will allow me to slowly embrace web technology into my current platform but also gives “native apps” a tab in the “browser” so to say. (from a consumer perspective) This also provides me an escape hatch if “native uwp apps” fail long term on the desktop.

The reason for above thinking is UWP does not provide me with an escape hatch as it can easily become the next Silverlight victim if there is no cross-platform capability soon. MS is hedging their bets with making sure they don’t lose out on the PWA trend or their hand is being turned therefor React native support on Windows. The problem is I took a bet hoping by this time there will be a “path” for UWP/c#/.net into the browser or cross platform and that I can reuse most of my investment into those platforms.

I remember when every developer out there shouted buy Xamarin, it took MS forever todo that. I think most developers that are familiar with web assembly know that recently they managed to run a “full version” of Windows Server in web assembly will say buy the Uno platform and make it huge with significant investment. If a full OS can run on web assembly MS should give every .net developer a migration path to cross platform capability to protect their existing investments.

You might say Blazor is there but frankly before I invest more time in a new platform I will rather learn React or you might say we MS have limited resource for all of this. Surely when you pay $7.5 billion for Github it all becomes relative.

I think it is critical that MS understand the reputational damage that a failed migration path to cross platform capability for existing UWP/Win32 investments. Cross platform capability should be synonymous with .NET 5 and it’s not. I’m not sure if baby steps to cross platform in this instance is going to work out for MS and believe me I have always been a huge fan of xaml/.net/c#

What templates would interest you most?

Do you mean project templates or item templates as well?

Would it help if Visual Studio or another tool automatically updated namespaces for you?

Would this just be a search and replace (less value) or also incorporate updating dependencies to new version (more valuable but not sure how you could tell)

Re: Backward compatibility for new features

Will being backwards compatible to Creators Update (15063) be a fixed reference point or will the plan going forward be to support the current version and X number of versions prior to that?

What will this mean for anyone creating an extension or own control or functionality they want to share publicly? Will they need to support that level of backwards compatibility too? Even to Windows 8.1?

Re: Migrating namespaces

Will it be possible to migrate an existing UWP in stages (I'm thinking pages) or will it be necessary to update the whole app at once? If it's the whole app in one go that will make adoption slower.

What about migrating WPF apps? - Is the migration strategy to use XAML Islands which could use WinUI 2.x or 3.x? Could both be used in the same app?

Yes, splitting this issue into multiple, more focused ones will help captures ideas more clearly and avoid tangents.

Please replace all instances of UWP with the appropriate names, as it's not clear what you're referring to.

@mrlacey:

Do you mean project templates or item templates as well?

Item or library templates are interesting too! There are some great points in the replies so far about providing additional boilerplate and starter code which is something else we could consider adding over time, perhaps like the Windows Template Studio.

Would this just be a search and replace (less value) or also incorporate updating dependencies to new version (more valuable but not sure how you could tell)

Good question - what kind of dependency updates would make it more valuable? e.g. finding new compatible NuGet package versions?

Will being backwards compatible to Creators Update (15063) be a fixed reference point or will the plan going forward be to support the current version and X number of versions prior to that?

We envision the support version range to change over time based on usage. Rather than being restricted to a specific number of versions, we will likely continue to look at usage data and support the most active in-market Windows 10 versions.

What will this mean for anyone creating an extension or own control or functionality they want to share publicly? Will they need to support that level of backwards compatibility too? Even to Windows 8.1?

We don't currently envision imposing any additional requirements or "certification" for custom controls. Versioning would be up to you. The overall versioning story across May 2019 Update, WinUI 3.0 and future versions of WinUI is definitely a topic we want to go into more depth on soon though.

Will it be possible to migrate an existing UWP in stages (I'm thinking pages) or will it be necessary to update the whole app at once? If it's the whole app in one go that will make adoption slower.

Great question - thanks for noting that. This is also a topic we want to go into more depth on soon.

Please replace all instances of UWP with the appropriate names, as it's not clear what you're referring to.

@riverar: is there a specific usage or section that isn't clear?

We use the term "UWP Xaml" to refer to the Xaml platform that's shipped as part of Windows 10 and the UWP SDK, in order to distinguish it from other Xaml-based platforms (e.g. WPF).

We also refer to the "UWP app model" (packaging and installing, data and state management, the runtime lifecycle, etc.), as distinct from a Win32 app model.

Even on Windows Desktops, users spend lots of time Browsing the Web.
I think that we need a way to develop decent Web Apps, using the (subset of the ) UWP vNext XAML + .NET (C#/F#/VB.NET)

I developed in WPF + ClickOnce for many years, then started to look at UWP. I like UWP, but it (or the next ver.) needs to be able to run standalone EXE, better Window APIs (allow to make a even custom Winamp Window style App if we WANT), more Printing APIs, easy interop with C dll, OCX, at least a subset of the Components should Run on the Web.

When I saw UNO, I tought: Microsoft could buy this company, and join these developers with the teams of UWP and Xamarin. I would be happy if the next version UWP become an Azure thing, that runs on Web, Windows, Mobile and IoT. IMO even Azure portal could be written in UWP vNext.

Microsoft can do it. You did it with Silverlight, you did WPF, you did UWP, you did Xamarin. Now is time for the ultimate GUI XAML framework. And, in my opinion, Web must be supported, at least a subset of the functionality.

_INotifyDataErrorInfo_

Please do not introduce new namespaces for stuff like _INotifyDataErrorInfo_ - it should be used in view models that are usually cross-platform and should not have dependency on WinUI. It should be defined where other stuff like this is located (i.e. _INotifyPropertyChanged_ or _INotifyCollectionChanged)_

About this topic. Windows.UI.Xaml.Interop already has a INotifyCollectionChanged interface and Windows.UI.Xaml.Data has INotifyPropertyChanged. These two will be moved to Microsoft namespaces. Perhaps the System.Runtime.WindowsRuntime assemblies can do some mapping from WinUI to .Net

My only thing I want to add if it hasn't been added already is, I 100% support the MSIX/Appx package model and Win10 has done a fantastic job of fixing the shit that was installation and removal over the lifetime of windows. However, I always struggled to build a "UWP" application because of the weird subset of available API choices that were made in the AppContainer sandbox. As a C++ developer, that was frustrating and every year seeing you open the sandbox up further to allow the full Win32 API set has been a relief.

So if WinUI 3.0 lets me build an app with access to 100% of the Win32 stack, then this will be golden! I've tried using XamlIslands right now, and it's a fantastic escape hatch, but it's been unstable for me and it's got some work left before it's truly across the finish line.

Getting project templates that let me build a Win32 app, without being stuffed inside an AppContainer process, and let me access all of the advancements you've made with UI, then WinUI 3 will be a perfect fit for me.

@eklipse2k8 There still needs to be a permission system for accessing a user's files and devices, even in a relaxed sandbox. Also I think there should be rules to keep in userland and avoid elevation to admin and kernal access - without some kind of official testing and code signing requirements.

Hello Microsoft,

I don't know how much this post will influence the topic of Font Rendering, ClearType, DirectWrite and the future of Windows UI but I'm one of the small but vocal & passionate few who have some serious grievances with the font rendering subsystems in Windows.

It is well documented pretty much everywhere on the Internet people's frustrations (or satisfaction) with Windows UI and font rendering. You'll find some people that love font-smoothing, and you'll find others that absolutely hate it.

I am not here to discuss whether one is better than the other. Nor am I here to discuss registry hacks, 'font tuners', or how I can tweak OS settings to make fonts appear better. Trust me, I've done it all; even going so far as doing research to write a kernel mode driver to patch DirectWrite functions in kernel mode.

I am here because I have a very common optic medical condition called myopia / near-sightedness. I can see things clearly up close. But just at arms distance, my vision is right at the edge of my visual acuity and where text starts to become blurry.

Beyond arms distance, I need to wear corrective lenses. :eyeglasses: I'm sure we're all aware, desktop computer screens are right at about arms distance. Hence the problem.

• Fonts that look smooth, look blurry to me.
• Fonts with sharp edges (snapped-to-pixel) look clearer to me.

When fonts are snapped-to-pixels, the sharp edges are a visual signal to my brain that my vision is clear and in focus. However, when I encounter font-smooth text, that visual signal tricks my brain to think that my vision is out of focus.

As a fellow developer who spends long periods of time writing code and looking at text, it's frustrating and hurts like hell. This is the major reason why I'm still running Windows 7 and not Windows 10. Almost all of Windows 10 main Metro UI is using font-smoothing everywhere.

To illustrate this font-smoothing issue, let's look at the services.msc MMC snap-in on Windows 7:

Do you see any blurry text that looks out of focus? Here. Let's zoom in a bit closer...

Goodness, gracious it feels like I'm looking at text cross-eyed in an autostereogram.

It turns out, in this specific case, digging through the control hierarchy of this window, the MMC snap-in hosts an Internet Explorer DHTML/ActiveX control which is rendering fuzzy text in the "select an item to view its description" panel. The sharp (snapped-to-pixel), "Help" menu and list of services is rendered with normal USER32 and GDI32 primitives.

This small example highlights one of the biggest issues with font rendering in Windows. It turns out IE8 will respect the global operating system setting that disables ClearType and font-smoothing. However, if you install IE9 or above, IE9+ will happily ignore any and ALL efforts to disable font-smoothing. IE9+ just doesn't care and forces all users to view text on websites (and in ActiveX controls) with font-smoothed text.

The problem gets worse for users like me because as time has moved on, the birth of Windows 8 and Windows 10, Metro Apps, WPF and UWP have all taken the same approach as IE9+. All of these UI technologies under the hood ignore global operating-system wide settings that should be respected on our machines. If we disable ClearType and font-smoothing at an operating system-wide level, we expect ClearType and DirectWrite APIs (and consequently, Metro, WPF and UWP apps) to not draw with any font-smoothing.

I know I'm not the only one with this problem.

A while back, Google Chrome did the same thing with their v31 release and tried following the IE9+ approach and switched all font rendering to DirectWrite ignoring global system-wide settings. This change put the Internet in rage. See Chromium Issue 319429. Finally, after much gnashing of teeth, Google reversed course and corrected the issue in Chrome 37 for those users with myopic visual impairment and now respect the operating system-wide setting that disables font-smoothing.

Thanks to the powers that be and market forces, Microsoft lost the browser war and is now adopting the Chromium rendering engine, but I hold with bated breath that the Edge team will respect disabled font-smoothing settings.

I am here only to advocate that Microsoft needs one global setting that needs to be respected, for all apps on the operating system, across all UI stacks, for those with visual acuity issues.

And as a friendly reminder, this is an accessibility issue for Windows UI in general, not one of visual preference.

On the basis of world-wide prevalence of myopia, it can be estimated that over 22% of the current world population, that is, 1.5 billion people are myopic. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3930268/

Thanks,
Brian

:walking_man: :walking_woman: Missing Persons - Walking in L.A.

This means that the full Xaml framework would be developed on GitHub and ship out of band as NuGet packages.

NuGet is great, but supporting vcpkg (and CMake) would also be appreciated (for those of us with large, existing cross platform libraries).

What templates would interest you most?

In preference order:
Win32 + Xaml Desktop + WinUI
Win32 + Xaml Islands + WinUI
UWP + WinUI

Were you aware of Xaml Islands for modernizing desktop apps?
Does this expanded backward-compatibility on Windows 10 make Xaml Islands more useful to you?

Yes, Xaml Islands is interesting, but as we target consumers, and not enterprise customers, the expanded backwards compatibility isn't a deal breaker - most customers are reasonably happy to update their OS (and given time scales for implementing changes based on new WinUI Xaml, having it locked down to 1903 would probably mean it's been out a year already).

The root namespace for Xaml, composition, and input APIs in WinUI will be different than the Windows UWP SDK root namespace:

Would it help if Visual Studio or another tool automatically updated namespaces for you?

This doesn't affect me, as we don't have a UWP app (currently use WPF for direct sales and WPF + Desktop Bridge for the store), but changing namespaces is a one time thing, and even in the largest code bases, a global find and replace for Windows::UI::Xaml isn't that daunting (we're all using version control right..?).

The fastest path to releasing WinUI 3.0 would be to not support mixing:

That's fine with me, they should be treated as separate incompatible libraries. You either target UWP Xaml, or WinUI Xaml. As mentioned above, the one time conversion shouldn't be that difficult.

However, one of our biggest concerns is the compatibility issues and work that could create for existing UWP apps and component libraries, particularly if you're authoring or consuming UWP Xaml control libraries.
For example, existing versions of the Windows Community Toolkit wouldn't be usable in WinUI 3.0 apps, so both the Toolkit and any apps using it would need to update before using WinUI 3.0.

Microsoft needs to pick a technology and stick with it. For years we've been promised the latest and greatest desktop UI frameworks (Win32, ATL, WTL, MFC, WinForms, WPF, UWP Xaml, and now WinUI Xaml). Whilst the choice is great, it leads to a fragmentation of functionality and developer knowledge. It's much easier to have one session / one webpage / one stackoverflow answer on implementing a feature in Windows, vs 7 different ones depending on the tech. If WinUI Xaml is the future, the Community Toolkit needs to be updated to take advantage of it.

How important to you is full compatibility between existing UWP Xaml components and WinUI 3.0 apps?

I've been holding off doing anything with UWP Xaml because the functionality just isn't there (in comparison to Win32 / WPF), and I assume I'm not alone in that respect. As such, full compatibility isn't an issue.

Do you create or use UWP Xaml control libraries or WinRT components that you couldn't easily recompile and update alongside app code?

No.

What would be your preferred solution for using UWP Xaml components with WinUI 3?

N/A

1. What do you think about the overall 3.0 plan outlined above and in the roadmap? Would it enable you to use WinUI for your new and existing Windows apps?

There's no mention of Xaml Desktop in the roadmap. Does this fall under the remit of WinUI?
I've mentioned this before to people at //Build/, but the reason for not adopting UWP Xaml before is that it was impossible to make an application that makes use of existing C++ libraries. For example, when a user chooses a file with FileOpenPicker, the result is delivered as an IStorageFile, and there is no way of passing this to an existing 3rd party library to open (e.g. libpng, libjpeg, etc). This is why we've had to stick with WPF, so if Xaml Desktop or Win32 + Xaml Islands allows us to live without these restrictions, then yes, it would enable us to use WinUI for a new application.

1. What kind of apps would you be most excited to use WinUI 3.0 for? Creating a new Win32 app and packaging it with MSIX? Adding new views to a WPF app? Modernizing a C++ MFC app with Fluent UI?

Creating a new Win32 app with WinUI (and packaging with MSIX).

If you've got any questions, please let me know, I'm happy to discuss further.

Actually hoping there is way to call Compact Overlay from WPF/WinForms.
We just need a administrator permission system like "Draw over other apps permission" in Android.

Hope this app model + packaging (UWP + AppX, Win32 + MSIX) allow that (Full Abstraction inside Sandbox)

Isn't Windows suppose to be most advanced and unlimited possibilities, with best security?
No by crippled feature for security.

Thank you for opening up to the community for input regarding the roadmap.

How important to you is full compatibility between existing UWP Xaml components and WinUI 3.0 apps?

On to the point, we have quite a number of UWP apps in use for enterprise clients right now, and I hope the migration path will not be that hard. If there's breaking changes It'd be very nice to have a migration tool similar to the .Net Framework to .Net Core that generates how compatible our migration path would be, this should report anything that might need changing (e.g. APIs that might be deprecated or behave differently) and an option to automatically change the namespace if possible. This way the migration path for UWP to WInUI will not be as volatile for us enterprise devs.

Were you aware of Xaml Islands for modernizing desktop apps?
Does this expanded backward-compatibility on Windows 10 make Xaml Islands more useful to you?

Yes, but wasn't much of a problem since moving forward all our newly developed desktop apps are using UWP communicating via an API backend, and most of our clients are already running Windows10.

What do you think about the overall 3.0 plan outlined above and in the roadmap? Would it enable you to use WinUI for your new and existing Windows apps?

The desktop team is already excited for the news of WinUI 3, but as stated above dreads the migration of all our UWP Apps to it if the path is not that smooth.

As for the general XAML since the whole XAML UI framework will live decoupled from Windows as others have voiced make it so that it's possible to swap out the renderers. This will open up the possibility of running WinUI XAML on other platforms which is a huge defining factor nowadays when people choose a stack to stick with, as evidenced with the popularity of Electron and JS frameworks taking advantage of such for small companies that do not have the manpower to specifically develop native codebases for each platform.

Also add that with WinUI 3 onwards should also improve on the XAML dialect as well, maybe introduce a version namespace / Doctype to specify which version of XAML is being used so to keep backwards compatibility for older apps. There's alot to be made on making XAML less verbose or chunk some boilerplate out, like having to write INotifyPropertyChanged with backing private setters for one instead of just being a simple property attribute say NotifyPropertyChangedAttribute and let the build step inject the implementation to avoid runtime overhead or DependencyProperties for custom controls to simplify making components. Maybe also take some of the improvements on the Razor team for some of the good parts they have.

These requests may or may not be feasible, but I love XAML and would love for it to continue to improve so I'll state some of the pain points (but still serviceable) I and some on our team had when developing for them.

@mdtauk I'm not opposed to file security but the underlying kernel should prevent you from writing in places you're not authorized to as opposed to using a whole new set of API and abandoning the win32 file API. Also, I know this is getting way off topic, but the StorageFile/StorageFolder api are horrible replacements, not even accounting for file security. They are slow and you're always proxied through the runtime file broker. Further, it should never have been a restriction that sandbox'd apps need special MS approved permission to write in user's documents folder. Just for example how crappy the file story for the AppContainer effort was, it was impossible to create a sqlite DB anywhere except in the user's hidden LocalData folder. For a desktop system where users want to create, save and open files, and save as, yadda yadda, it put the burden on the software developers that they needed to retrain their users how to manage users' content.

As far as administrator access, the Oct 2018 release added "allowsElevation" as an entitlement, which makes sense. An app could allow a user to run as administrator if they need that broad system level access for some feature set. We're not all building cute little photo editors and flow chart apps.

@MarkIngramUK Thank you for your comments, Just one clarification. The Xaml Desktop concept that was presented in a Sneak Peek at //Build 2019 has been renamed to WinUI Desktop. This new Visual Studio project will use a Win32 app model, with WinUI as presentation framework, and it can be native or managed (using .NET Core 3).

Thanks @marb2000 - is this within the WinUI 3.0 timeframe?

@marb2000 by WinUI Desktop, you mean Win32 apps with Xaml Islands? Which build session was this shown in?

One thing the WinUI team should watch out for with the WinUI 3.0 rename: If you rename any of the types that are projected in .NET, then the projections won't work (and we aren't planning on adding any more since it's not a maintainable extensible system). Here's a list of the types that we project: https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h

Any changes to different types than these types will require users to wrap their objects in new objects that implement the new interfaces or copy their data into the new types. In particular, the INotifyPropertyChanged and INotifyCollectionChanged types are of interest with respect to XAML Islands and providing downstream support.

INotifyDataErrorInfo

Please do not introduce new namespaces for stuff like INotifyDataErrorInfo - it should be used in view models that are usually cross-platform and should not have dependency on WinUI. It should be defined where other stuff like this is located (i.e. INotifyPropertyChanged or INotifyCollectionChanged)

About this topic. Windows.UI.Xaml.Interop already has a INotifyCollectionChanged interface and Windows.UI.Xaml.Data has INotifyPropertyChanged. These two will be moved to Microsoft namespaces. Perhaps the System.Runtime.WindowsRuntime assemblies can do some mapping from WinUI to .Net

Thanks for the reply, but why you need it in Microsoft namespace if .NET Standard has it in System.ComponentModel already? https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifydataerrorinfo?view=netstandard-2.0

@meir-pletinsky. NET is only one framework you can use to make apps with UWP XAML. They want text field validation available for Devs, no matter what framework they use

@mdtauk , no, WinUI Desktop (previously Xaml Desktop) allows you to use Xaml with Win32 directly, without the use of the island.

@marb2000 It'd be great if the Application Packaging Project allowed you build an AppX with a Win32 window and include WinRT components in the same easy way that a UWP project does. There's lots of things that don't work without manually editing the vcxproj files such as adding resources and cppwinrt compiler generating the headers from included WinRT components.

Another Project that is important for this new UI is the _PropertyChanged.Fody_ by Simon Cropp that allows automatic implementation INotifyPropertyChanged (I tried with C# / F#). See https://github.com/Fody/PropertyChanged

It allows a simple code like this:

[AddINotifyPropertyChanged]
public class Person
{
    public string Name { get; set; }
    public string FamilyName { get; set; }

    public event PropertyChangedEventHandler PropertyChanged;
}

wich we can use to Bind to the UI.

One thing I would like to see in WinUI 3.0: Currently, the UWP XAML compiler (genxbf.dll) can only be invoked directly by MSBuild when referenced from a csproj, vbproj, or vcxproj file. This is because there is no command-line tool that can be used to invoke this functionality. This strikes me as a very weird decision, as nothing else in the Windows 10 SDK download requires Visual Studio. (The WDK add-on also includes Visual Studio targets, but those targets all invoke command-line tools that are usable independently of VS.) I would greatly appreciate the addition of e.g. XbfCompiler.exe and XbfCodeGen.exe to the SDK’s bin directory. (The former EXE would compile XAML files to XBF files, and the latter would generate the code-behind files that are required to reference XAML types from code.) This would be mainly useful in C++ projects that use CMake or another, non-Visual Studio build tool, but could also be used for C# and VB.NET projects if required. Thanks!

@MarkIngramUK do you happen to know where I could learn more about WinUI Desktop. Those Build 2019 sessions are not available to watch online. Sounds like important information that should be linked to in this repo

@mdtauk It was mentioned in a so-called Sneak Peek, which is only for Build attendees. Afaik there's no recording. I was also not there, but there's a slide - maybe the best slide :-) - available on Twitter: https://twitter.com/RudyHuyn/status/1126273995366490113

@mdtauk The WinUI 3 roadmap has the latest information and diagrams which are even more up to date than what was shown at the Build sneak peek. There’s no such thing as “XAML Desktop” nor “WinUI Desktop”... that was just a confusing word choice on a slide that got photographed. The concept being communicated (and the roadmap tries to explain this more clearly) is that for WinUI 3 we are working to make it so you can have a project template that creates a new traditional Desktop/Win32-model app using WinUI 3 for it’s UI (just as today there are templates for UI frameworks like WinForms, WPF, MFC, etc. on top of the traditional Desktop/Win32-model) in addition to an updated UWP/WinRT-model app project template that uses WinUI 3. Does that help clarify?

The 3.0 roadmap seems quite reasonable for the following strategy: enable any Windows client app to use XAML and the "modern" WinUI controls.

However, this strategy seems short-sighted if one considers the reality of the today's market: for a lot of app development, Android and iOS are the primary targets, and Windows is a nice to have. For the .NET developer, Xamarin gets you decent Android and iOS support, but their Windows support is sub-par. So for native mobile/desktop apps, Win UI 3.0 does nothing to simplify cross-platform development for .NET developers.

What I'd really like to see is a go-forward XAML dialect with truly universal aspirations. I should be able to write a .NET app using XAML, and have that app run on Windows, iOS, and Android. The app should be truly first-class on each platform and have access to native elements as needed. As mentioned, Xamarin is a good start, but its dialect of XAML is very different, it has poor Windows support, and none of the work that you're doing helps.

So, tldr, good that you're continuing to provide a modern UI platform for Windows. Good that you're making it easier to use from different kinds of apps. Bad that you're not aspiring to cross-platform support.

Optionally disable or opt out of the legacy-mobile application lifecycle behaviors, such as suspend + tombstone.

The reality is that UWP is a desktop environment and at least for games, the user may often minimize the app which usually leads to suspending/tombstoning the app. This is a jarring experience and one that is very different from any win32 desktop app or game. Requesting an extended deferral, which will likely still expire, is not enough to seamlessly deal with this.

While this lifecycle is handy for some apps, it's detrimental to others. Ideally a desktop app or game should be able to declare a capability that allows for the app to opt-out of the suspend+tombstone lifecycle model, which would prevent it from being eventually suspended when minimized.

@natemonster

Per: https://docs.microsoft.com/windows/uwp/launch-resume/run-minimized-with-extended-execution

On desktop devices, extended execution sessions created with ExtendedExecutionReason.Unspecified have a battery-aware time limit. If the device is connected to wall power, there is no limit to the length of the extended execution time period. If the device is on battery power, the extended execution time period can run up to ten minutes in the background.

A tablet or laptop user can get the same long running behavior--at the expense of battery life--when the Allow the app to run background tasks option is selected in Battery usage by app settings.

@TonyHenrique when you mention Fody, is this because you want to create an awareness of it, or are you saying it should be built in to WinUI?

Item or library templates are interesting too! There are some great points in the replies so far about providing additional boilerplate and starter code which is something else we could consider adding over time, perhaps like the Windows Template Studio.

@Jesbis I'm a core contributor to Windows Template Studio and am watching the WinUI roadmap with a view towards what we do in the future and how we introduce support for WPF. ;)

what kind of dependency updates would make it more valuable? e.g. finding new compatible NuGet package versions?

Being able to detect NuGet updates would be more useful but there are other potential compatibility issues with taking updates. I'd make detection of new versions and automatic conversion a low priority. There are so many considerations that it would be a big project in it's own right and I'd rather see time invested in the platform that a tool like this.

@mrlacey I mentioned Fody because I think it is an interesting solution and we need a better way to avoid the _INotifyPropertyChanged_ boilerplate code. It would be good to have a MS supported solution to this concept of a Reactive object that automatically raises a event when some property changes.
It works on C# classes and even on F# Records (but had some difficulties).
So on the WinUI roadmap there should also have this.

Note: It would be good if we also could use the F# records to define our data entities and Bind then directly to the XAML UI. It would be cool if we could be using F# Records + Fody + DataBinding without problems .

[<PropertyChanged.AddINotifyPropertyChangedInterfaceAttribute>]
[<CLIMutable>]
type Person =
    {
        ID: Guid

        mutable Name: string
        mutable Addresses: ObservableCollection<Address>
    }

This would be more familiar for folks coming from C#.
Another approach would be the Elmish way. I think that both are interesting, and could be supported.

@tonyhenrique / @mrlacey I think the Fody stuff (OAP) should be out of scope. The WinUI team have enough on their plate already, and I think it's better to have the weaving in separate projects (much faster release cycles in case of improvements).

And I think this is actually a .NET (IL) implementation detail of the models, not actually anything to do with WinUI (although it can listen to the change events). My suggestion is to keep them separate. For example, I use Catel and it has its own Fody weavers to make sure everything gets weaved correctly.

What I'd really like to see is a go-forward XAML dialect with truly universal aspirations. I should be able to write a .NET app using XAML, and have that app run on Windows, iOS, and Android. The app should be truly first-class on each platform and have access to native elements as needed.

There is a long standing proposal to go in that direction: Cross platform UX for .NET 5 - original title Cross platform UX for .NET Core 3.0. The overwhelming support of community for it is obvious and we can hope that MSFT will realize that this is the best direction to develop any UI framework working on .NET. There is pretty much no reason to keep separate codebases for different platform groups and forcibly creating separate developer skill sets based on different UX frameworks supported by .NET.

By creating single UX for all platforms we cancel all inefficiencies in framewrk development and lower the barriers to developer adoption. Only these two aspects should be sufficient to consolidate all UX XAML based frameworks.

@mfeingol / @4creators , I would settle for

The app should be truly first-class on each platform

on Windows to start with...

It's 2019, I want a fast, native UI, and I don't want to have to seriously consider making a user interface with CreateWindowExW, GDI, etc.

Now that with WinUI3.0 and above the code is decoupled from Windows 10, are there plans in the future for WinUI to work on Linux and Mac?

@jesbis Touch interactions will be kept in WinUI 3.0?

Thanks for the clarification, I had assumed the way 3.0 would work was to include Xaml Islands in WinUI, rather than use the Community Toolkit.

With it becoming XAML plus Win32, it makes more sense, especially with the Windows Core OS rewriting it's shell in XAML.

As I understand it now, this rich Win32 API access is in C and C++ | with anything in C# relying on .NET (all be it now .NET Core).

Perhaps there should be a safe and simple way to access these Win32 APIs, as well as more entry points for displaying an apps UI?

• System Tray XAML flyout for WinUI 3 apps

• simple Picker UIs for Hololens/Xbox/Surface Hub/IoT, etc

• updated XAML customisable Common File Dialogs, and folder pickers

• simple C# .NET access to Win32 APIs

• compact setting for all XAML elements, which match Win32 and WPF control sizing (this will help Frameworks to sit comfortably together)

• matching control styles/fonts/accent brushes/acrylic when using WinUI

• clear definition of which devices require the WinRT/Mobile lifecycle

• Xbox Next control styles built in for Xbox app development and testing on Windows

• Store and single exe/MSI/APPX packaging and downloading supported by default, NO INSTALLERS, centennial type file system virtualization by default

• WinForms WinUI 3.0 - simple UI, access to MFC, mouse and keyboard only

• WPF WinUI 3.0 - dense UI, 3D rendering, DPI aware, simulated touch and basic ink support

• Xaml WinUI 3.0 - full touch, MR, gamepad, inking, voice, mouse, keyboard. Dense and simple UIs. New windowing support. MR 3D rendering. Optional managed lifecycle, or desktop lifecycle. Best of all worlds default for shell and reworked inbox apps, with Win32 versions of inbox apps like notepad, charmap, paint, file explorer - open sourced and available from the store.

Touch interactions will be kept in WinUI 3.0?

@r7dev yes, the plan is to keep the same level of touch support.

F# is ignored on the WinUI 3.0 roadmap. Microsoft ignoring one of its products once again.

Win32 API Thoughts

Something I also thought about is the reason win32 has stuck around too. I think there's an assumption that this is because of legacy projects, but it's actually quite deeper than that. The Win32 ABI is super easy to hook up with your language of choice, nodejs, python, rust, go, ruby, c#, c++, etc. etc. If my core project is in rust for example, and I want to generate a window to manage the output, as a rust developer, it's super powerful to access the win32 API set and build a front end in the same language.

On OS X, to access AppKit you just needed to bridge the objc_msgSend C API and gain access to the entire obj-c infrastructure. All of those languages above did a really good job of bridging that and it made it easy to write in your language of choice and produce something compelling.

So if you want to to make WinUI 3.x be the true path forward for accessing low-latency, low-memory, high quality Win32 UI, you need to consider the ease at which other language maintainers can tap into the infrastructure.

UI Consistency

If you're really planning to decouple the UI from the system, what is the plan for the UI remaining consistent with each OS upgrade? When Apple makes tweaks to shadows and gradients in AppKit or iOS, Apps that rely on the system frameworks inherit all of those tweaks and remain consistent. It's also going to make it hard for you to add system-wide experiences because Apps that are locked to UI infrastructures 3 years ago may not operate well with some new system service, so they will have another compatibility layer as time goes on.

There will always be features that need to be opt-in, I can think of Dark Mode as something that if the app wasn't designed for it, it really wouldn't make sense to offer it as an option, but there are still tweaks to system components that would change over time.

Binary Size

What is the planned story for delivering all these UI.dlls with our projects? Will these things be 40mb of runtime that need to ship with our projects? What will happen if a project is abandoned, will they start to look outdated because they use old UI frameworks?

One of the benefits of C++ is that it has a minimal amount of library overhead depending on the codebase. Certainly if every single app from here on out required WinUI 3.x, that is going to be 40mb x number of apps.

Binary Size

WinUI is already a dependency, just like .NET is. It's already a system-wide library. :)
You don't have duplicated dlls, and you won't have it.
https://www.microsoft.com/store/productId/9N00JJ7S3L39

@eklipse2k8

"Something I also thought about is the reason win32 has stuck around too. I think there's an assumption that this is because of legacy projects, but it's actually quite deeper than that. The Win32 ABI is super easy to hook up with your language of choice, nodejs, python, rust, go, ruby, c#, c++, etc. etc. If my core project is in rust for example, and I want to generate a window to manage the output, as a rust developer, it's super powerful to access the win32 API set and build a front end in the same language."

This is a mixed bag though as while implementing WinRT support for a new language is a huge hump to get over, once you do, you end up with autogenerated typed bindings to any new APIs. I've been working on a Rust project that bridges Win32 and WinRT recently (using the Composition APIs in a Win32 window), and the Win32 parts have definitely been more of a pain overall even though I've had to clumsily work around the remaining lack of Rust support for some WinRT features like class inheritance. (It does definitely help that using Composition inside Win32 is now possible, since it allows incrementally improving support for this feature instead of having to tackle the entire app model all at once)

Probably the biggest problem is that the documentation for low-level WinRT ABI details is kind of disorganized, and there's just very little understanding or awareness of them in the world/community, I'm hopeful this situation will improve with the xlang project though.

What templates are you most interested in?

Currently I prefer to start from a Blank App (Universal Windows) project. I like templates with a preconfigured framework too, but only when i want to try out something quickly. A "Main Menu" Template and MDI Template for UWP would be nice too (as those templates exists for WinForms too)

Were you aware of Xaml Islands for modernizing desktop apps?
Does this expanded backward-compatibility on Windows 10 make Xaml Islands more useful to you

Yes, I'm aware of Xaml Island. If I can, I'll try to stick to a pure WPF or pure UWP app. I wasn't in a situation where I'd would require such a feature.

Would it help if Visual Studio or another tool automatically updated namespaces for you?

Yes, sure if it works reliable! I'm surprised by the many comments which don't appreciate such a nice feature. Also this feature could check if an update to WinUI 3.0 is doable, adopt the XAML Code, adjust the namespaces and install the required WinUI nugets.

How important to you is full compatibility between existing UWP Xaml components and WinUI 3.0 apps?

I would expect to change only the namespaces of the control to work full with WinUI 3.0. I don't want to invest much time in upgrading to WinUI 3.0

Do you create or use UWP Xaml control libraries or WinRT components that you couldn't easily recompile and update alongside app code?

I'm using third party UWP Xaml control libraries (like Windows Community Toolkit, https://github.com/kakone/VLC.MediaElement ). I think I would be able to upgrade simple controls from third party libraries like a Dockpanel by myself to WinUI 3.0.

What would be your preferred solution for using UWP Xaml components with WinUI 3?

• Create a "Blank App with WinUI 3.0" project template in Visual Studio for UWP. The WinUI 3.0 dependency will be installed as nuget (like in WinUI 2.0).

The fastest path to releasing WinUI 3.0 would be to not support mixing [...]. I absolutely would prefer such a solution as long, as I get all basic controls. I would expect that all classes from Windows.UI have an equivalent class in the Microsoft.UI Namespace.

The main topic in WinUI 3.0 was all about controls and windows 10 compatibility which can be used from UWP and WPF or WinForms via XAML Island, if I'm correct. Are there any chances that the UWP XAML Markup gets somehow additional features?

• Style Triggers missing
• Style `BasedOn={StaticResource {x:Type TextBlock}} missing
• Defined DataTemplates with DataTypes aren't automatically applied like in WPF (only via Key)
• Why is every second Windows.UI.Xaml.Controls control (TextBlock, Border,...) declared as sealed?! Please don't do this in WinUI 3.0 with UWP.
• Markup Extensions for WPF parity
• This was already mentioned, but I'm gonna mentioned it one more time. Its sad that UWP doesn't make use of the System.ComponentModel.IDataErrorInfo. That way I can't share my Model project with the UWP solution.
• ReportControl (for Enterprise Applications)

I'm really looking forward to WinUI 3.0 and its backward compatibility !

F# is ignored on the WinUI 3.0 roadmap

Are there any chances that the UWP XAML Markup gets somehow additional features?

@Happypig375, @mfe-:

The roadmap only covers the initial 3.0 release, and for the initial release we're mainly focused on parity and backward compatibility for existing features, with a small number of new features.

If you think other new features like better F# support or new markup capabilities are important then please do open a new feature request so we can track them separately!

Why is every second Windows.UI.Xaml.Controls control (TextBlock, Border,...) declared as sealed?! Please don't do this in WinUI 3.0 with UWP.

Unsealing controls is actually one of the small number of new features we're hoping to include in 3.0 😊

When it comes to languages, it would be neat to mix and match (which should be fine if everything is compiled down before packaging)

F# used for some back end logic - C# for Databinding and UI code - C++ for controls and maybe some low end Win32 hooks or even to launch a WinForms dialog.

All code languages are equal, interchangable, with WinUI 3.0 handling all the UI

That’s xlang 😉

That’s xlang 😉

@MarkIngramUK Hmm, I thought it was a bridge between languages, which abstracts each language, rather than allowing code files from multiple languages in a single project.

I have kind of struggled to understand the purpose of xlang - glossing over the updates that have been happening in the repo (but still have it in my watching list)

Does xlang work pre or post compiling? Is it its own abstracted language which can be projected, or does it just sit between existing code files?

Yes, you can’t mix languages in a single project. It’s a bridge, but still useful for those purposes.

@MarkIngramUK I guess so if its code that can be compiled then included.

It would be good to be able to use C# to access native Win32 features, without PInvokes and other .NET tricks

@jesbis I'm honestly more interested in a cross-platform aspects of this project...

I think that at start, you guys should rename it to something more _generic_ and not strictly to "Windows".

I got it that the initial implementation should be strictly focused on Win32 and back UWP/Xamarin apps and Windows but just OSS it and make it from the beginning called like a "Windows-only" framework, will definitively not get much traction just like UWP didn't and developers from other platforms would never get interest on it.

If the target on .Net 5 is to be "One .Net Everywhere", which is basically what everyone always expected since .Net 1.0, the foundations for "Anything but Win UI" framework should start cross-plat.

A very good example on how to make it right is Google Flutter. Flutter is on its very early days, but got A LOT of traction due to the fact that their core (aka Flutter Engine) is 100% cross-plat and works everywhere (including IoT, Win, OSX, and now even Web!).

That is just my 2c. I would love to get back to work on Xaml but if it keep on the same line as on UWP, I'm afraid it will not get the right traction and will be another attempt to re-write WPF that will eventually need another attempt in the future and so one so forth.

Please don't take me mad and don't take my comment as a bad criticism. I just wish that the efforts on the UI on .Net world would get something like Flutter, .Net Core 3.0/.Net 5, and even Blazor.

For the record, I event started a project to rewrite/port Flutter engine entirely on C# and .Net Core due to the lack of options on .Net World...

BTW, CoreUI is a good name...

Kudos to Jake Helfert for that suggestion 😄

💃

BTW, CoreUI is a good name...

Kudos to Jake Helfert for that suggestion 😄

💃

CoreUI may get confused with .NET Core

WinUI is very much focused on Windows, but the XAML framework within it, could get renderers for Metal (iOS and macOS) or Vulkan (Android) - and FabricWeb could be the PWA/ChromeOS way to handle the other platforms.

If the team ever choose to bring the presentation platform over, and Xland or Xamarin could handle the runtime for cross platform apps.

About the migration from inbox UWP UI to WinUI 3.0, I'll quote a recent blog post from @dotMorten ( https://www.sharpgis.net/post/2019/05/14/The-future-UWP ):

Fun bottom note: What’s happening to UWP is not that it’s being killed: Microsoft is pivoting bringing the bests parts to where we need them. This actually happened before, but it was unfortunately not used as an opportunity to perform a pivot. Remember Silverlight? Guess where .NET Core’s cross-platform CLR came from. And lots of Silverlight’s code also ended up in UWP. Had they only pivoted and said “Yeah we agree Silverlight doesn’t make sense in the consumer spare, but it’s thriving in the enterprise space, so let’s build on that, and we’ll evolve it into .NET Core and Windows Store”. Unfortunately that didn’t go so smooth, and lots of people still suffer from PTSD and wary of whatever Microsoft does that appears to be killing off any technology.

I really think it's important to remember that being perceived as killing off or resetting existing frameworks without giving developers and codebases a good way forward doesn't just affect developers on the existing framework - it can cast a cloud over future efforts as everyone wonders why the new thing won't just meet the same fate. This isn't meant as a remark on any specific proposed migration approach, more a response to the comments to the effect that migration doesn't matter because not many people are using the existing inbox UI framework. That's not the only consideration!

@weitzhandler WinUI 3.0 is about combining various Win32, .NET Core and UWP frameworks with a single XAML framework, and interoperating with WPF, WinForms, and MFC++

XAML on Windows is rendered down to Direct X.

If you wanted to take that same XAML, combined with .NET Core, and make it work on other platforms. You would need to write new renderers for those platforms. iOS and macOS use Metal as their Direct X equivalent. Android uses Vulkan. No idea how Linux handles rendering, I would guess its just Open GL.

Microsoft will not want to do that themselves because it does not make sense for them. But WinUI 3.0 will be open sourced - so others could choose to try to bring it cross platform

@mdtauk

Thanks for clarifying that. Flutter is probably the future for me.

That is just my understanding, I could be mistaken.

Flutter is supposedly getting Windows support in the future. And React Native support is coming to Windows also. Plus there are PWAs if you are invested in that Web HTML and Javascript world.

To me the whole WinUI story can make more sense if they also take in consideration allowing at least a basic subset of it run cross-platform (macOS, iOS, Android) including Web, and also offer a better F# support and project templates (including XAML Two-Way Binding to F# Records, and also a more functional Elmish way)

XAML needs to be environment agnostic just like HTML is without taking 100mb+ for even the most basic tool apps as HTML apps do. This means a XAML framework that is written in pure C/C++ or C# and can be hosted in WASM, Win32, UWP, iOS, Android, macOS, Linux etc with minimal effort when it comes to porting. You need an agnostic rendering backend like game engines use to start with.

None if this UWP focused XAML is solving any problems my company or me personally has had for years with XAML... and thats portability. TBH MS is going about UI completely wrong and its going to get no where fast (its wasting a lot of valuable time for a lot of people). This UWP XAML hackery just doesn't come off well to people I show it to... which is sad because it just means a never ending push back against the adoption of XAML and I have no more arguments at this point.

The only way to save XAML in my opinion is:

• Create a new agnostic / portable framework base for .NET Core and C/C++.
• Create an agnostic rendering abstraction layer anyone can extend via pull-requests.
• Just like HTML keep the XAML focused on single windowed app concepts (just as is done in games as well) BUT allow extended desktop features for multi windows etc. (This allows the app to run in almost any context just as a games UI can)

Simply put there are two conditions that have to be combined into one before XAML adaption will be excepted.

1 MS needs to back the XAML project or people fear it falling out.

2 It needs to be cross-platform or everyone is going to be stuck with crazy bloated HTML runtimes.

Anyway thats my two cents and if WinUI 3.0 is designed right maybe porting will be possible. At this point though idk what to feel.

There's a few comments about being cross platform in here, and I'm not so sure that WinUI would need to be cross platform to be successful. It wouldn't work well on Mac or Linux anyway, as it's different enough that it wouldn't feel native on either of those platforms. This project is owned by a team that has a wealth of knowledge about how Windows internals work, and it would be a distraction for them to go off and figure out how to also make something work really well on Mac or Linux to same degree.

Also... Fluent on Mac would feel clunky, just look at iTunes, Apple had to port their entire UI system to Windows, and it definitely feels out of place. Font rendering is different, the animation curves and shadows and color choices just feel so out of place in Win10. I mean, it's fine and usable sure, but I prefer spotify which doesn't try to emulate any desktop UI and just uses a web browser under the hood. On Mac, seeing the reveal spotlight with square components in a desktop full of rounded corners and no reveal effect would clash so hard.

No, I think this project should focus on offering the best in class way to make native Windows software, for developers who want/need to build windows software. Leave the cross platform stuff to the Electron/Typescript teams to solve.

There's a few comments about being cross platform in here, and I'm not so sure that WinUI would need to be cross platform to be successful. It wouldn't work well on Mac or Linux anyway, as it's different enough that it wouldn't feel native on either of those platforms. This project is owned by a team that has a wealth of knowledge about how Windows internals work, and it would be a distraction for them to go off and figure out how to also make something work really well on Mac or Linux to same degree.
Also... Fluent on Mac would feel clunky, just look at iTunes, Apple had to port their entire UI system to Windows, and it definitely feels out of place. Font rendering is different, the animation curves and shadows and color choices just feel so out of place in Win10. I mean, it's fine and usable sure, but I prefer spotify which doesn't try to emulate any desktop UI and just uses a web browser under the hood. On Mac, seeing the reveal spotlight with square components in a desktop full of rounded corners and no reveal effect would clash so hard.
No, I think this project should focus on offering the best in class way to make native Windows software, for developers who want/need to build windows software. Leave the cross platform stuff to the Electron/Typescript teams to solve.

I don't think anyone really wants full Fluent design on other platforms, but rather just be able to maximize common code between platforms.

This is something that has already been addressed by the Microsoft Design team. The Fluent website explicitly says "design and build custom apps that are natively iOS while still uniquely Fluent". The Fluent docs show that native control styling should be used.
https://www.microsoft.com/design/fluent/#/ios
https://developer.microsoft.com/en-us/fabric#/controls/ios/button

What should be avoided, is having to design and maintain completely separate UIs for each platform. That doesn't mean that it needs to look identical on the surface, but should share a common layout, and UI designers should be able to reuse as much as possible. The actual styling does not (and should not) need to match the Windows 10 system styling.

In essence, what is wanted is an easy way to get Windows apps running on other platforms, without having to remake the entire UI - not to bring Fluent design to other platforms. That would enable people to write for Windows first, and then bring their app to other platforms without a lot of work.

@KyleNanakdewa Well if they're open sourcing it, let some Xaml fans go off and create the underlying platform bits. I think it's probably architecturally complex enough and takes advantage of Win32 enough that i suspect the port would be a massive undertaking.

I think this project should focus on offering the best in class way to make native Windows software

This argument might be compelling if Microsoft didn't already own an existing cross-platform XAML toolkit that just happens to offer a very different dialect of XAML than WinUI.

Plus there are PWAs if you are invested in that Web HTML and Javascript world.

Yes... "that world" which is quickly replacing everything we know about native OS/Store/Hosted development. 😆

https://onezero.medium.com/the-end-of-app-stores-is-rapidly-approaching-b972da395097

Consider "that world" exists on _all_ modern devices with an HTML5 renderer:

• Apple with 1.4 billion
• Droid with 2.5 billion
• Windows 10 with 800 million

You will notice that Windows now has the smallest market share, meaning that any offering that caters specifically to this platform will be one that reaches the smallest marketplace. Doing so only lowers an application's maximum potential market reach which, in turn, lowers its maximum potential revenue ceiling.

Compare this with Flutter, which with _one_ codebase reaches _all_ of the aforementioned marketplaces, along with the web, which as mentioned is composed in aggregate of all three -- therefore maximizing market reach and potential revenues for application developers while reducing the necessary costs of building applications to do so.

While I am a huge fan of the efforts here to open source, collaborate, and solicit community feedback, I have yet to see anything from these discussions (which I also enjoy 😁) that signal to me with any confidence that the efforts here will be competitive -- and therefore _profitable_ -- when compared with the likes of Flutter (which btw is also gearing for PWAs).

Diagram control is essential in any data driven modern desktop experience in soon to be official NET CORE 3 (Sept 2019) and eventually. NET 5 (Nov 2020)

I see the provided Networkview open source control as an effective use case on how to work with Xaml to port WPF to Win UI control. This ported Win UI will serve as a good guild for others to port other slightly more complex WPF controls to Win UI.

We see 2 in 1 use case where our app need to support the tablet mode in future Windows Core OS. We suspect Winform in. NET Core 3 will not help.. another strong justification why Win UI diagram control is NOT just an exercise of PoC BUT should be part of win ui core controls in similar FIRST class as Grid control moving Forwards..

If you think other new features like better F# support or new markup capabilities are important then please do open a new feature request so we can track them separately!

Seems @migueldeicaza is taking matters into his own hands: https://github.com/microsoft/microsoft-ui-xaml/pull/736

I want to echo @eklipse2k8 's thoughts on cross-platform. When making a cross-platform UI library you will always have to make compromises. WinUI should not compromise - it needs to be the modern replacement of Win32 UI (I don't want to be calling CreateWindowExW any more!) and it needs to be a showcase of what you can do on Windows. WinUI on macOS or Android would always deliver an experience which could never match the native experience. We write cross-platform applications, and we write native UI on each platform. That way the customers get the best experience on their choice of platform. If people want a cross platform solution, that's fine, they should look to another library for that purpose - perhaps one that wraps WinUI on the Windows platform.

And with regards to PWA, these do not represent the full use of the Windows UI system, recommending focusing on "single window applications" would immediately rule out any professional piece of software (except games). There are solutions already for PWA and cross-platform - we don't need another one.

Obligatory XKCD:
https://xkcd.com/927/

@MarkIngramUK I think the talk of Cross Platform is more about being able to code to .NET and XAML for declaring UI - then to have that app run on Android, iOS, macOS, Linux?! - without having to change the code behind or abandon the XAML.

Now if there were XAML Renderers for these other platforms - how they interpret the XAML could be like Xamarin Forms, which hands over to native UI platforms - or just essentially draw to the graphics card buffer and draw the pixels on screen - maintaining most of the same controls styles.

WinUI 3.0 should remain a Windows focused project to unify the various APIs and ABIs with a modern XAML based UI platform. But that doesn't mean Xamarin or individuals can't take the rendering code and make versions for other platforms.

All that would be needed really (at a high level of thinking) is to ensure the code that renders XAML to the screen in Windows is contained, so other renderers could step in for cross platform scenarios.

WinRT/UWP/XAML is going to need some refactoring to extricate them from the Windows 10 OS - so how that refactoring is done, to allow for future expansion, is something to keep in mind. Whether cross platform becomes a reality or not.

@MarkIngramUK I agree with @mdtauk

There should be no reason why we can't use xaml to describe UI components in other libraries including React. If you look at a project like http://www.cshtml5.com , they use xaml that gets converted to html.
I also don't think anyone alludes to the fact that the end goal is for the UI to look the same on other platforms but what I personally want is something on the UI side that I can use to leverage my existing investment in eg UWP

The point is simply this. If I make a proposal to a enterprise customer and present an awesome UWP app that is fantastic in all respects. If that enterprise customer has 1 user that is using for example a MacBook Pro, then I immediately have a problem as the enterprise customer will rather take something that works everywhere (lowest denominator => website) than my "native app" even if they run on Windows 10.

So accessibility is key. The fact that MS is still expecting us to make investments in "native apps" in 2019 without any roadmap to cross platform capability is crazy.

Any new project from a enterprise perspective is likely to follow the above logic for accessibility and therefor all new projects will be biased towards the web and all because there is no roadmap that includes cross platform capability on XAML/UWP

So then we fast forward 2-3 years from now , no new investment from companies into UWP/win32 and you are sitting with another "Silverlight" that nobody cares about.

MS can even tell me that XAML is deprecated tomorrow and the "new" UI library is for example React. As long as c# can be glued to this new library then I will cut my losses, dump XAML and embrace this new cross platform UI library. At least my investment has durability and is accessible long term.

By not providing clarity on this specific issue around cross platform UI capability, MS is creating uncertainty around their "native stack" and therefor most enterprises will rather run throught a fire with a wooden leg than embrace the unknown.

And with regards to PWA, these do not represent the full use of the Windows UI system

Fair enough, and I agree. My primary point with PWA was to demonstrate that its market share dwarfs any single particular market, as it is comprised in aggregate of all markets.

That said, I suppose part of the confusion here on my part is the namespacing to reflect Microsoft.*, when really it sounds like it should still be Windows.* (or even Microsoft.Windows.*).

There are solutions already for PWA and cross-platform - we don't need another one.

Unfortunately, this is not the case for .NET development, which is part of the confusion and cross-platform angst around this announcement and subsequent discussion.

therefore maximizing market reach and potential revenues for application developers while reducing the necessary costs of building applications to do so.

Sometimes performance and UX details can make a big difference. Skype has maximized market reach using Electron framework at the cost of sacrificing performance and the result is the commercial disaster.

Regarding cross-platform (xplat) solutions.
Xplat solutions are an abstraction over multiple native underlying systems. My understanding of WinUI is that it will be the native system for Windows.

If WinUI was to also be xplat, how would it incorporate things that are unique to Windows? Wouldn't that prevent it from doing new and innovative things? Or would that mean it's on Microsoft to port anything new or differentiating from Windows to other platforms too? What about things that couldn't be ported because the other underlying OS couldn't support them--should they not be added to Windows?

If you build something with native Windows technologies, it's reasonable to assume that Microsoft will support that for a period of time and provide a path forward to newer Windows based systems in the future. (Acknowledging SilverLight as an exception.) I don't think it's reasonable to assume that if you build something with native Windows technologies and then want to run it on a competing operating system then it's up to Microsoft/Windows to make that easy. If you built an app for the iPad with Swift and wanted to also bring that to the Windows desktop, would you expect Apple to change iOS development to make that easy?

If you enjoy or prefer using native Windows technologies that's great. What you can't do is defer the business decision you make in choosing those technologies to someone else. All technology choices have consequences and no-one knows what might be required a few years in the future or what your customers might ask for. Asking for software developed specifically for Windows to also be able to run elsewhere can give the impression that the aim is to avoid making a technology decision that could have possible negative consequences at any point in the future. Based on the nature of technology and the speed of change I don't feel that's realistic.

That said, if you want to build an xplat solution (and there are lots of people who do & reasons for that) because you either want to target multiple operating systems now, or may want to in the future, then that's a reasonable and understandable scenario.
For that Microsoft have Xamarin. Or, if you'd prefer something with XAML more like UWP, there's Uno. (There's lots of other options too.)
If, like me, you want to see Xamarin have better native support for building Windows apps, I don't think having WinUI try and do mulitple things is the answer.

WinUI is about more than just XAML and specific controls. It includes details of how those controls and the apps that are built with them integrate with the underlying operating system.
If WinUI planning focuses on making Windows development on Windows the best it can be then that's a good case for having innovation and good future support. It's also likely to increase the chances people will want to continue using Windows and therefore it becomes important that it has solid support from multiple xplat solutions.

Regarding cross-platform (xplat) solutions.
Xplat solutions are an abstraction over multiple native underlying systems. My understanding of WinUI is that it will be the native system for Windows.

Sorry but I don't feel that way...

Look at Flutter... It has a core engine that can render anything on any platform it supports.

On top of that, it has components that are fully implemented on Dart using the engine managed layer and that represents (draw/render) in pixel fidelity the platform and design language you want to use for example, Material.io and Apple's Cupertino.

So, that IMHO, that would be the best approach to make something cross platform and that at same time represents the underlying platform capabilities.

I don't think it's reasonable to assume that if you build something with native Windows technologies and then want to run it on a competing operating system then it's up to Microsoft/Windows to make that easy

Right... I think the point here that others are making is that this seems a bit backward/tone-deaf these days, especially in the context of starting a new application. Why would someone build a native Windows application when that only reaches a small % of the market? This is not a good use of capital.

If it's to maintain legacy Windows applications or to specifically make a Windows application, then yes I am in agreement with all of this and it makes sense. However, since there appear to be breaking changes and further investments involved, the value proposition of doing this vs. using Flutter has yet to be explained.

That is precisely what I'm saying...

For example, the flutter embedders for Desktop on both Win10 (WPF and UWP) as well as OSX are coming.

They are 100% managed by flutter runtime, but they are only using (for example) WPF/UWP to get the windowing management and Graphics pointer. All the rest is managed by the engine...

We've ported flutter engine ourselves to an embedded ARM device and I have to say it was an awesome experience. Why? Because it born to be portable and to run anywhere by letting the "embedder" to deal with platform specific implementation details on primitives like GPU, Software rendering, Input management, etc...

That is why I'm saying that WinUI by means of UWP: The empire strikes back is not going to work long term.

MSFT must come with something cross-platform, open, and portable. Just like they did with .Net Core, with Blazor, etc... Reinvent UWP/XAML will not going anywhere.

I believe XAML has a good potential if used properly in a sense where it is used to "describe" (or declare like some say) the UI. The "engine" build the render tree from it, and then dispatch the render commands to the underlying platform.

Like MSFT recently did with Chromium as the core for Edge, I believe WinUI (or whatever the name it became) could leverage Skia as it has backends for GL, DX, Vulkan, Software Rendering, FB, etc... Just by starting with that you have a HUGE potential of adding other platforms later...

@galvesribeiro ,

Look at Flutter... It has a core engine that can render anything on any platform it supports.

On top of that, it has components that are fully implemented on Dart using the engine managed layer and that represents (draw/render) in pixel fidelity the platform and design language you want to use for example, Material.io and Apple's Cupertino.

Great, so as soon as Apple release an update to macOS, and the UI updates (perhaps button corner radius changes, or background gradients change, etc) your Flutter application doesn't update and continues to look like the previous OS - unlike a native control which would get the benefits for free.

@MarkIngramUK that is the work on the team to support updates.

Just like Xamarin team provide updates from day 0+1, this team could do the same. Google team does that as well...

By using the "native" control, you are back again on Xamarin world were you only do, wrappers (aka Renders)...

We're not discussing C# bindings to native controls (Like Xamarin does)... We are talking about a full UI framework like you do with Flutter...

For the record, nobody uses the "default" theme for any platform. They all create their unique UX on top of the design languages of each platform.

If you are so concerned about having alway look as the native component, your app probably will never have good audience as they would look... Meh...

I believe we're talking about two different projects here. WinUI needs to be the Win32 replacement. People are asking for a cross-platform solution, which is reasonable, but I don't think it should be this project.

Also, Flutter allow you to use the "theme" on all platforms. So you can run Cupertino on your Win10 PC. A BIG example is Material design. It is a design language, not a set of controls. It can be used anywhere... It just happens that some platforms (like Android) has its native controls implementing it...

@MarkIngramUK

I'm just clarifying why WinUI should not be just a Win32 replacement, thats all.

If that is the case, then I'm pretty sure it will fall in a foreseeable future just like UWP...

I agree @MarkIngramUK WinUI itself should be focused on providing a unified UI for Windows, no matter whether you use C#, WinRT APIs, Win32 ABIs, C++, F#, VB, .NET Core.

WinUI 3.0 involves lifting all that code and rendering of XAML out of the Windows OS, and making it a framework, independent from the OS update cycle, and making it open sourced.

How it is lifted and repackaged is still up in the air. Only those internal to Microsoft know how they will do it. In order to support future cross platform support for XAML, I only hope some thought is put into how it could be achieved in the future, as they are extricating it from Windows.

.NET Core is already available on other platforms. So that's the C# code behind already transferable. It is now just XAML and the UI and controls, which need a path to iOS/macOS/Android/Linux (and whatever may come in the future)

Outside of the scope of WinUI 3.0 perhaps, but most definitely linked to this project and effort.

@jesbis @terrajobst @jevansaks

What are Microsoft's plans for bringing a UI framework into .NET Core that renders on desktop, mobile (Droid, iOS), and web?
The uncertainty about this has been going on for very long.

@weitzhandler, they already have a roadmap, with the following paragraph:

A native Windows target for web and cross-platform frameworks
WinUI 3 is better optimized for libraries and frameworks to build on.
For example, we're planning to base the new high-performance C++ React Native Windows implementation on WinUI 3.

Note the emphasised part, "to build on". As I've been saying above, there's no reason why this can't be Windows first, with other libraries building on top of it.

Ok then...

/me keep working on FluSharp

which is reasonable, but I don't think it should be this project.

It's thirsty out there @MarkIngramUK, pardon our projections. 😅

with the following paragraph

Doesn't say much. It doesn't reveal MS' clear intention for making C# and .NET development xplat. It maybe says that HTML JS & CSS shi{ are better equipment for you than C# if you want to be portable.

At the moment, Xamarin and Xamarin Forms is Microsoft's story for C# and .NET Core development outside of Windows.

React Native for Windows is coming for Javascript code and Native UI (which will use WinUI 3.0 XAML)

At the moment Microsoft has no plans announced for bringing WinUI 3.0's XAML to other platforms.

WinUI the project is trying to unify the Win32, WPF, MFC, UWP, .NET Core dev frameworks, under a single modern XAML presentation framework.

I think after that, work should go into finding ways to render XAML written for WinUI 3.0 - on platforms like macOS, iOS, Android, etc - but that is not on the agenda so far.

Once WinUI 3.0 work starts on here, it will be open source, so that makes future cross platform work possible for the future, if there is enough need for it. And it may not be Microsoft who eventually make these cross platform paths available, it could be the open source community.

Any plans on making F#, .NET's redheaded stepchild a first class citizen? And then people wonder why the vast majority of .NET developers won't touch F# with a ten-foot pole.

At the moment, Xamarin and Xamarin Forms is Microsoft's story for C# and .NET Core development outside of Windows.

Yes, Xamarin.Forms is being ported to macOS, GTK, UWP and WPF, plus having material design everywhere in the works, which makes it the de facto .NET UI Framework, but it is so slow and buggy I wonder what Microsoft is thinking about its developers. Just look at the issue list! Once serious development started, bugs are hit left and right. I hope with WinUI we can finally have a better development experience.

Re: F#

If you think other new features like better F# support or new markup capabilities are important then please do open a new feature request so we can track them separately!

Yes, it's always F# that get separately tracked and ignored again. Just look at UWP and .NET Native - both didn't have F# in mind and the community at large had to figure everything out. 🙄 After 4 years, F# still is unsupported on .NET Native.

For F# suggestions/questions I created a dedicated issue:
https://github.com/microsoft/microsoft-ui-xaml/issues/740

Please feel free to direct F# discussions there.

We're definitely not ignoring the feedback on it - having a dedicated issue just helps us organize and track it.
The team is discussing how it could fit into the roadmap for 3.0 and beyond and will update the new issue with any developments.

RE: cross-platform UI:

Thanks everyone for the points raised so far, and for the passion about .NET and Xaml.
I just want to say again that we're listening closely to all the feedback, and we'll share our thoughts and updates as we progress.

Just to reaffirm the current roadmap and some points that have come up:

WinUI is the native UI platform for Windows (including native apps, not just .NET) and for the initial 3.0 version we're primarily focused on making it independent of the OS and working toward getting it ready for open source development on a faster release cycle. We want to make sure the scope is feasible enough for us to get a preview out this year.

One of our other current short-term goals is to enable WinUI to serve as a native target for other platforms to use on Windows: for example we're also working on ensuring react-native-windows - a high performance C++ React Native implementation for Windows - uses WinUI, and that WinUI controls can be used to create native UI views in React Native apps.

I'll be perfectly honest. I have a native Windows desktop app I wrote in 2006 on WinForms that I'm still selling online today.

I have no plans to migrate this app to WPF, UWP, or use any exclusive windows UI technology. I don't care how compelling the Windows demos look. If I ever decide to work on this app again, the next major version will be some kind of cross-platform implementation that can run on MacOS, Linux, and Windows.

Currently, that would probably look like Blazor + .NET Core + Electron.

I think @Mike-EEE makes some great points. The UX/platform that allows me to leverage my C# skills to reach the greatest number of audience is the more likely technology I'll be picking.

Microsoft should focus on empowering developers to leverage their existing skills to reach a greater audience with their apps. I think that's a winning strategy and will keep Microsoft in the game.

The writing on the wall is that Operating System software is becoming more like a commodity. That being, people can pick any OS they want and get the apps they want to use. I think this will become more apparent as time moves forward as the world's software vendors continue to focus on cross-platform.

In economics, a commodity is an economic good or service that has full or substantial fungibility: that is, the market treats instances of the good as equivalent or nearly so with no regard to who produced them. https://en.wikipedia.org/wiki/Commodity

Microsoft has to decide, does it want to be part of the developer tooling story? Or does Microsoft invest millions of dollars into a new Windows-only UX stack that will just end up joining the graveyard of UX stacks that fewer and fewer people use?

This project is owned by a team that has a wealth of knowledge about how Windows internals work, and it would be a distraction for them to go off and figure out how to also make something work really well on Mac or Linux to same degree.

It's a tough position to be in for sure. But times have changed. The world today is very different than the world that was in 1995. The way I see it, there's a couple of options:

You could hire more people to expand that knowledge beyond Windows.

Or, use that team's knowledge to build UX plumbing inside Windows that enhances compatibility for cross-platform UI application frameworks to run better on Windows.

Just like WSL did for running Linux on Windows.

• Use the team's knowledge to make GTK run 200x faster.
• Use the team's knowledge to make QT apps run 200x faster.
• Use the team's knowledge to make Electron apps render faster than any other OS.

There's a lot of work that can be done to enhance the Windows cross-platform UX compatibility story. But investing in a whole new UX stack and hope that we all switch (without any cross-platform story) is a pretty big bet. Ya'll gotta break this habit creating new UX frameworks only for Windows.

Just my two cents. :moneybag:

:horse_racing: :cowboy_hat_face: Lil Nas X - Old Town Road (Official Movie) ft. Billy Ray Cyrus

@bchavez

Ya'll gotta break this habit creating new UX frameworks only for Windows.

-- Not only that. Even the habit of breaking Windows own internal XAML portability. WPF, Siliverlight, UWP all on their own fork... This kind of thing is pushing more and more people away from Windows dev tools in general which I personally would like to keep using in the future. The more push back from Windows dev tools means the less and less C# is relevant and for me its what I care about when I get down to it.

RE: cross-platform UI:

... WinUI is the native UI platform for Windows (_including native apps_, not just .NET) and for the initial 3.0 version we're primarily focused on making it independent of the OS and working toward getting it ready for open source development on a faster release cycle. We want to make sure the scope is feasible enough for us to get a preview out this year.

Add a +1 for the idea of updating the visual look for WinForms, MFC, WPF controls running with WinUI 3.0 to better match the Fluent/FabricWeb control styles.

Sure different control sizes (anything not WinRT XAML should probably match their metrics to the Compact version of the UWP controls) but one coherent and consistent polished look.

Add a WinUI 3.0 dependency into WinForms and the controls change.

WinUI 3.0 WPF apps detect and use Fluent.Light.xaml or Fluent.Dark.xaml control Themes.

@weitzhandler I understand your sentiment. I hope to never have to touch javaScript, and similars to do this cross-platform GUI. I dislike even thinking about starting a project using electron, angular, dart, flutter.
I hope we can have a solution soon with .NET 5, that will bring the Universal XAML dream. Microsoft XAML can WIN, Web, Mobile, Desktop and IoT.
Silverlight almost did it, for many use cases.

Ya'll gotta break this habit creating new UX frameworks only for Windows.

WinUI 3.0 will never get released if we've got to wait for (an inevitably compromised on all platforms) cross-platform support. WinUI should be the lowest level UI framework on Windows, and if you want cross-platform ability, build on top of that (or use React Native, Xamarin, etc).

Ya'll gotta break this habit creating new UX frameworks only for Windows.

I'd just like to clarify that we aren't trying to create a new UI framework with WinUI 3.0.

Our initial goal is to:

• remove barriers to using the existing modern native technologies (Windows 10 Xaml UI and compositor) by decoupling them from the OS and enabling them to work across existing app models (win32 and UWP), languages, other frameworks (via islands), and Windows versions

• update our engineering process to be open source

WinUI 3.0 will never get released if we've got to wait for (an inevitably compromised on all platforms) cross-platform support.

Man... If you really believe on that, you mean that successful frameworks like Flutter doesn't work...

I don't like Dart either, but they DO released a pretty descent product which is evolving and getting traction REALLY fast.

I'm frustrated that WinUI will become only a Windows things...

.Net needs a UI framework that match the awesomeness of .Net Core cross platform capabilities just like we just got for Web with Blazor (client and server-side).

I think for now, we still have to rely on community-driven efforts.

I understand what your team is trying todo @jesbis... It is just that many of us are tired of seeing UI on .Net/C++/UWP/MFC/Windows a _silo_'ed thing that only run on Windows while all the world (ofc except Apple and OSX) are going the opposite way offering developers better and better cross platform solutions. Like you mentioned the React and Rect-Native (for the record I don't like either, just mentioning they are evolving).

So what we have now is just community driven initiatives like Avalonia or even Uno and other frameworks (like FluSharp that I'm working as mentioned) that evolve VERY SLOW for obvious reasons...

My suggestion is that rather than just lift the XAML and compositor out of Windows codebase and make it a Windows-only, to get it and make proper abstractions so it could work on multiple platforms. Just like we had with .Net Core, which was initially Windows-only but that community driven efforts made it work pretty fast on Linux, OSX and even on ARM devices...

(an inevitably compromised on all platforms) cross-platform support

I really don't think this will be a problem, given that cross-platform design is, and has always been, a key aspect of UWP's XAML UI, and Fluent Design. There are definitely some controls where the visual design is different between Windows versions - this is handled seamlessly, you get native UI that matches the device's OS.

For example, Acrylic and Reveal built into controls, accent colours on Pivots and NavigationViews - these things don't appear on the Creator's Update, but do on FCU and newer. Zero changes required.

Obviously there is a lot more complexity behind-the-scenes to rendering the UI on an entirely different OS, but in terms of actually designing the UI, I don't think there's any new considerations that need to be taken, than there ever was with UWP and WinUI.

I think the big concern is what the long-term plans truly are. Based on responses from @jesbis it seems like they're only focusing on the short-term right now, and long-term plans are still open for discussion.

That much is understandable, the scope of such a project is huge. I could absolutely understand if it wasn't the short-term plan, but rather the endgame plan. Transparency is important here, it's clear that no one wants to support a platform without a clear future.

It's clear that MS as a whole is focused on cross-platform - we see this with Fluent Design (which now has examples for iOS, Android, and web), a large number of MS-made apps on other platforms - so shared UI is really just a big missing link. And that is why it would be so disappointing to not see it happen - I think a lot of people like the idea of a MS-made universal app platform, but it doesn't make sense to support, if we don't have a complete solution for it.

The point is... As with material.io and Cupertino, we could (and I'm not surprised if Google isn't already doing that!) have the "theme" on flutter for fluent design language...

And that is my point when I said that a truly cross-plat UI framework would not care about that and would just work, like Flutter does... I don't see where we have compromises on that...

@weitzhandler I don't like HTML for native apps either. Otherwise I would be using Electron with React 😄

I'm just not being passional here, and just being rational instead.

I am really looking forward for the WinUI 3.0 and I would use it immediately for a new C++/WinRT Windows desktop project. And I hope that the next major version after 3.0 will introduce a portable runtime for hosting the WinUI applications (like the Flutter runtime). For a significant number of LOB applications and Photoshop like applications, the GUI can be the same on each platform, but the key is the performance and source code reuse. And I also think that the xlang project is a great idea and promises some good news in a future.

I suggest users here take time to listen to Scott Hunter after BUILD 2019 on how Win UI, Xamarin Form, UNO, Web Assembly could come together.

.NET Core 3 and Beyond with Scott Hunter@.NET Rock

Both Xamarin Forms (XAML) and UNO (XAML) were created with the vision for cross platform. In the case of UNO (in addition to iOS, Android, XAML for Web through Web Assembly).

UWP was created with no vision of beyond Microsoft ecosystem e.g Web, Android, iOS. All the impressive Fluent design effort has little take up due to slow adoption of UWP

As @Mike-EE pointed out, droid and iOS have 2~ and 1.5~ billions while Win10 has 0.9 billions. Most of which developers are still reluctant to jump from WinForm and WPF to UWP.

WHY? The UWP controls, from commercial and Microsoft, are INCOMPLETE!!!!! compared to those in WinForm and WPF. There is no effort by Microsoft to help that transition. XAML Island will not address this AS LONG AS MICROSOFT has BLIND SPOT as what are missing that developers NEEDS to transition to UWP from winForm and WPF.

With these missing UWP Controls, now significant effort is putting on bringing Win UI to React Native for Web. ?????? We need these missing Win UI Controls for UWP so we could lobby for transition from WinForm and WPF to UWP.

One such control is Diagram Control. All data intensive business app needs diagram control for UWP.

==> I understand the need to decouple UWP UI. This only makes sense to spread Fluent Design branding to other platforms e.g. iOS, Android, Web.
==> Please focus on delivering better 3D model control and Diagram Controls (both 2D/3D)

It only makes sense to staying and wait for NET5 when ALL BCL from (mono is merged with the native of Windows, for Web Assembly etc ) , because I SEE THE FUTURE OF HOLOLENS creative 3D UI.

For that we need 2d/3D Diagram Control for UWP and 3D model control that should not just merely displaying model But allowing developer to access the skeletal/vertex animation.

@jesbis I urge you to put more people into these USP (unique selling points) of Win UI for UWP.

@weitzhandler

This issue was created to discuss the WinUI 3.0 Roadmap.

@jesbis made a clarifying statement:

WinUI is the native UI platform for Windows (including native apps, not just .NET) and for the initial 3.0 version we're primarily focused on making it independent of the OS and working toward getting it ready for open source development on a faster release cycle. We want to make sure the scope is feasible enough for us to get a preview out this year.

Your first two comments were on-topic.

The following six were a combination of non-productive and derogatory, and you are close to breaking the Microsoft Open Source Code of Conduct.

This should remain a productive, professional conversation with Microsoft.

// I'm not following this conversation to listen to some guy vent all day.

I think there's some great comments here, although it seems there might be two seperate discussions. I'll keep it short because most of it has been said before.

Cross platform & web

.NET Core is great. We can finally target every platform and touchpoint with great tooling and an awesome language.
The only thing that's missing is a UI stack except for Blazor (HTML / CSS sucks though). For max comparability it would be great to have a framework that allows desktop devs to migrate to web and beyond with the same skills, tooling and language (Xaml and C#). Tbh, Silverlight did a great thing there - it just worked). I'm not sure if WinUI needs to be that framework, but please raise the issue internally. Basically Flutter for .NET devs, and targetting web would be the biggest advantage.

Not sure if Xamarin could be that platform, but if so - make sure the Xaml is aligned as much as possible across WinUI and Xamarin.

WinUI

This needs to happen. There should be one common Xaml stack to create the best experiences possible on the Windows platform. Ideally the missing gaps from WPF in terms of controls and functionality should be filled.

HoloLens and beyond

With Lite coming up, and new super exciting form factors such as HoloLens one could argue that UWP is not ready for it in terms of UI. Yes, we can run them on a HoloLens which is nice, but I'd like to see a way to really optimize apps for 3D without going full Unity.

WinUI is way ahead Xamarin. But Microsoft Team just push Xamarin 4.0 out...
I am personally like Xamarin more as it is lowest denomination for Cross Platform, there gonna rising number of Native Apps for SaaS in future.

Other than Xamarin, there is some alternative.
1) Why not embrace UNO platform and make the web rendering using SkiaSharp?
2) @zezba9000 You need an agnostic rendering backend like game engines use to start with. Actually I kinda acknowledge it....

Maybe Microsoft push WinUI more, because there is non open source code trace inside unlike other cross platform solution: Xamarin, UNO, might have UNIX libraries...

Anyway, may the force be with you.
PS: Github Sponsor are from Microsoft, so please sponsor some notable Mac/Linux Developer for WPF/Winforms's Cross Platform fork.

@jkoritzinsky , One thing the WinUI team should watch out for with the WinUI 3.0 rename: If you rename any of the types that are projected in .NET, then the projections won't work (and we aren't planning on adding any more since it's not a maintainable extensible system). Here's a list of the types that we project: https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h

Any changes to different types than these types will require users to wrap their objects in new objects that implement the new interfaces or copy their data into the new types. In particular, the INotifyPropertyChanged and INotifyCollectionChanged types are of interest with respect to XAML Islands and providing downstream support.

I agree and I'm glad you brought up this issue, although I'd like to add that I think these projections are a bit of a unfortunate evil. We don't project every single API that probably should be (thinking about the System.IO APIs), so we should either remedy that, or think differently. One thing that comes to mind is to not add types that are similar, but different, to .NET types in a different namespace. Instead, we should enable our C++ developers to also use System.ComponentModel.INotifyDataErrorInfo. This is sort of what we did with C++/CLI, but this wouldn't require loading the CLR for a pure C++ application. I don't know if that would be more confusing, but it feels like we're leaking the fundamental and underlying differences in the .NET and WinRT technologies at the API layer, which makes things feel incoherent.

@meir-pletinsky. NET is only one framework you can use to make apps with UWP XAML. They want text field validation available for Devs, no matter what framework they use

This is right on the money, we do have C++ developers that we care about. Although like I mentioned above, I would love us to not cause confusion in the .NET community just to make this happen.

@mdtauk , no, WinUI Desktop (previously Xaml Desktop) allows you to use Xaml with Win32 directly, without the use of the island.

I think @meir-pletinsky was referring to .NET/C++, unless I'm missing something?

@MarkIngramUK I believe we're talking about two different projects here. WinUI needs to be the Win32 replacement. People are asking for a cross-platform solution, which is reasonable, but I don't think it should be _this_ project.

Yes, I totally agree! To me, WinUI is about defining the most modern, performant, just all around best UI for Windows. Xamarin should be the cross-platform story from Microsoft and should evolve to be on top of WinUI.

@mdtauk

Add a +1 for the idea of updating the visual look for WinForms, MFC, WPF controls running with WinUI 3.0 to better match the Fluent/FabricWeb control styles.

Sure different control sizes (anything not WinRT XAML should probably match their metrics to the Compact version of the UWP controls) but one coherent and consistent polished look.

Add a WinUI 3.0 dependency into WinForms and the controls change.

WinUI 3.0 WPF apps detect and use Fluent.Light.xaml or Fluent.Dark.xaml control Themes.

I don't really want to see MS investing time and resources into those frameworks to make them look like native Windows 10 apps. That's why there will be WinUI 3.0. You want Windows 10 look & feel in WPF/WinForms apps? Use WinUI 3.0.
MS should much rather invest their resources into closing existing (and blocking) gaps between UWP/WinUI and their Win32 counterparts, than re-visit their older frameworks. Especially given that WinUI is meant to become _the_ presentation framework for Windows...

I'd like to ask for clarification on WinUI and Microsoft's intentions on UI/UX:

1. Does WinUI replace ALL of the following (hypothetically?): Win32, ATL, MFC, WinForms, Silverlight (I know), WPF, UWP and/or XAML Islands? I recognize that these technologies will continue to exist, and will continue to be supported for some indefinite amount of time; I just want to clearly understand that this is what Microsoft is saying is "the way forward", and that (for example), we should consider WinForms and WPF the same as we consider Win32 or MFC.

2. Does WinUI derive from UWP? (Or, how similar are the two?) How similar (or different) is WinUI as compared to UWP, XAML Islands, or WPF?

As a professional C# and C++ developer, I started working with WinForms, and then moved to WPF, and then moved back to WinForms simply because I could design UI/UX for business purposes in WinForms roughly twice as fast as I could in WPF. WPF gave much more flexibility, performance, and looked much better—but the XAML mangling that occurred as soon as someone touched the interface via the Designer instead of hand-editing the XAML was awful. In some cases, I think WinForms (using the Designer) was orders of magnitude faster than hand-constructing a XAML form or control that was similar.

Personally, I would love a UI that's available and identical across Microsoft's products. A framework that can be leveraged by Win32 or .NET in a similar fashion would mean consistent, modern looking applications for ALL Microsoft developers, and would also mean that common questions and problems can be solved in sessions that target a single technology—for example, when asking a question about a control, the answer would be identical (if not nearly identical) for a Win32 developer OR a .NET developer. That would make learning "WinUI" useful for either stack for any given developer, and would also make access to information online (StackOverflow, etc.) much more valuable, regardless of where you're developing. Although I don't use Xamarin, if Xamarin could be made to follow in these footsteps (as an extension of WinUI?), then the above statement could be applied not only to Windows developers, but also those targeting Android, iOS, etc.

What kind of applications would I be excited to use WinUI for?

If my understanding of WinUI is correct, and it's "the way forward", replacing Win32, MFC, Forms, WPF, etc., and the same framework is available for native or .NET development, then I'll eagerly be replacing the composition in _ALL_ of the applications I support. Modern, consistent UIs, that work (and behave) the same regardless of platform or stack? Isn't that what we all want? I don't think anyone wants to remember how to both CreateWindowEx() and run a Message Loop to dispatch events in Win32 whilst handling events in a completely separate manner in WinForms or WPF. It's time for something "modern." I really hope that's what WinUI (3.0) is.

OS Compatibility and Downlevel Support

I think it's great that WinUI is focusing on decoupling the composition from the OS, but there are a huge number of customers who aren't even on Windows 10 yet. I know it's a pain point, and we all wish our target audiences were running the latest, but it's a real problem all of us face on a daily basis. What discussion is being had about making WinUI available to older platforms beyond 1703, which I believe is the currently-targeted eldest platform?

Is making WinUI statically-linkable or embeddable (like .NET Core/5) an option? We're going to have to target Windows 8.1, Windows 8, Windows 7—even Windows PE. How can we use WinUI with those requirements?

@shidell:

Does WinUI derive from UWP? (Or, how similar are the two?) How similar (or different) is WinUI as compared to UWP, XAML Islands, or WPF?

WinUI 3.0 will in a sense be the next version of the UI platform components of Windows 10/UWP, including the Xaml platform, composition and input. It comes from that codebase.

It should be very similar to the Windows 10/UWP Xaml platform APIs aside from what's mentioned in the roadmap: namely a different root namespace, better support for mixing and matching with other technologies (e.g. using a win32 app model instead of UWP), and some new additive features.

Does WinUI replace ALL of the following (hypothetically?): Win32, ATL, MFC, WinForms, Silverlight (I know), WPF, UWP and/or XAML Islands? I recognize that these technologies will continue to exist, and will continue to be supported for some indefinite amount of time; I just want to clearly understand that this is what Microsoft is saying is "the way forward", and that (for example), we should consider WinForms and WPF the same as we consider Win32 or MFC.

WinUI is where our main active development and progress is for native app UI on Windows. It is also what Windows itself and native Microsoft apps and devices use.

Xaml islands will be part of WinUI, and enable you to use WinUI to create new views in existing apps (e.g. WPF, WinForms).

What discussion is being had about making WinUI available to older platforms beyond 1703, which I believe is the currently-targeted eldest platform?
Is making WinUI statically-linkable or embeddable (like .NET Core/5) an option? We're going to have to target Windows 8.1, Windows 8, Windows 7—even Windows PE. How can we use WinUI with those requirements?

Thanks for sharing the feedback on this. For 3.0 we're focused on the platforms in the roadmap (1703+, with some support on 8.1). We definitely understand that developers have customers on other versions too, and that's something we plan to evaluate going forward.

Awesome—it sounds like WinUI is "the way forward", and given this understanding of it, to say I'm excited would be an understatement.

In particular, I think it's fantastic that XAML Islands will allow developers to extend WinUI into older technology, like WPF and WinForms. That's a great bridge "forward" while working on/extending old(er) projects.

Awesome—it sounds like WinUI is "the way forward", and given this understanding of it, to say I'm excited would be an understatement.

In particular, I think it's fantastic that XAML Islands will allow developers to extend WinUI into older technology, like WPF and WinForms. That's a great bridge "forward" while working on/extending old(er) projects.

I would like to think if a WinForms, MFC, or WPF project was created with WinUI 3.0 included - they could just render XAML pages/content/windows without having to use a XAML Island in a Form/WPF Window/HWND Window.

The ability to just use pure XAML, or use an Island to place XAML into the framework provided surfaces - would truly make WinUI 3.0 "The One UI to rule them all"

would truly make WinUI 3.0 "The One UI to rule them all"

... on Windows. 😉

WinUI 3.0 will in a sense be the next version of the UI platform components of Windows 10/UWP, including the Xaml platform, composition and input. It comes from that codebase.

On that note, @jesbis, I am wondering if you can speak for how integration will go between WPF and UWP. In particular, with concepts such as markup extensions which we have been asking for in UWP for years now, with very little success.

An attempt was made, of course, but has fallen way short of the WPF implementation despite taking over two full years to develop.

Additionally, a great deal of services that were available in WPF markup remains to be available and implemented in UWP. Is the effort here to ensure that new UWP-based WinUI 3.0 markup will have full fidelity with WPF? Apologies if this is explained somewhere, but I have yet to parse the messaging to see it (and welcome any resources to correct/supplement my understanding).

would truly make WinUI 3.0 "The One UI to rule them all"

... on Windows. 😉

At least for WinUI 3.0's release window. I am hoping it could be the start of a process to bring XAML rendering to other platforms...

I am wondering if you can speak for how integration will go between WPF and UWP. In particular, with concepts such as markup extensions which we have been asking for in UWP for years now, with very little success. [...] Is the effort here to ensure that new UWP-based WinUI 3.0 markup will have full fidelity with WPF?

@Mike-EEE full fidelity with WPF isn't a goal for 3.0. However we are tracking a number of work items to close gaps over time (e.g. #741 markup extension improvements - please do take a look and leave a comment on whether this would meet your needs!) and continue to expand WinUI beyond WPF (e.g. #686 3D model support).

If there are other specific features in WPF that you would want/need to use in WinUI then please feel free to open new feature proposal issues for them, or comment in the recent "WPF features that should be in WinRT XAML" issue #719. We don't have infinite resources but we're definitely trying to account for community input in our planning. Once everything is open source there will also be an opportunity for anyone to potentially help contribute features.

That is encouraging, @jesbis thank you for sharing that. I have updated the relevant votes on UserVoice to point subscribers to that issue.

I guess my outstanding concern is if full WPF fidelity isn't a goal, while having WinUI utilized within WPF _is_ a goal, then you are going to encounter friction with WPF adoption, as it has the superior (and original) Xaml model.

That is, there does not appear to be an obvious value proposition for incorporating WinUI3.0 into WPF, in much the same way that Xaml Islands do not have an obvious value proposition. At the end of the day, it would seem that you are attempting to bring in a regressed/inferior/underdeveloped Xaml model into the established and superior Xaml model, which simply does not make any sense.

For use cases in WinForms, MFC, etc., yes this approach makes sense for WinUI3.0. However, with WPF, it has a superior presentation model and developer/designer paradigm that simply has not been matched by any other initiative by MSFT or external vendors.

@Mike-EEE based on Scott Hunter's talk, it seems to me, which could be wrong, that the goal of "ONE BCL To Rule them all" comes at a higher priority than the "One UI to rule them all".

By replacing MONO underlying Xamarin Forms XAML and UNO XAML in Web though Web assembly with a common BCL that has AoC, apps based on Xamarin Forms XAML, Uno XAML on Web will ALL BENEFIT from the speed performance.

This speed performance IS CRITICAL to anyone who care about the future of their career investing in C# for cross platform in views of intense competition coming from other technologies e.g. flutter, react etc.

Hopefully, in this journey towards .NET5 = a common BCL to rule them all, XAML standardization is taken care, partially or completely, along the process, BUT not the main goal of .NET5.

Another priority on top of the need for XAML standardization is the spreading of Microsoft branding through fluent design to all platforms (mobile, desktop and web). [In technical term, decoupling through Win UI 3.0, which we are asked time and time again to focus the purpose of WinUI 3.0 roadmap]

IN THE END, how much UWP, which Win UI originates, actually plays a role in this ONE BCL TO RULE THEM ALL by NOV2020 when .NET5 is released, IS ALSO NOT a high priority goal in my view.

From marketing point of view, unfortunately not translated to technology that we care deeply, is that Microsoft branding through fluent design is ubiquitous and the app promoting that design is FAST EVERY WHERE.

This is how I see Microsoft long term strategy to "Catch up the market share" due to lack of mobile presence.

This is obvious except I SEE A FAR GREATER POTENTIAL lies in Hololens 2 and beyond. For that, WE NEED TO MAKE SURE UWP APPS with WinUI 3.0 come with 3D Diagram controls and advanced 3D model viewer.

Sorry guys, I keep pushing this as I want to use the limited time I have on the BEST OF THE BEST TECHNOLOGY. :-)

Regarding the WinUI 3.0 transition period

I would suggest that Microsoft work directly with the Windows Community Toolkit maintainers (some of which work for MS) in order to:

1. Test to see if there are any unforeseen roadblocks while retargeting the toolkit to WinUI 3.0 (including the sample app).
2. Test out automatic namespace renaming via Visual Studio or "another tool" to see how smooth it goes.
3. Publicly report on how the process went (blog post/GitHub issue/whatever you like).
4. Provide a copy + paste chunk of text about WinUI 3.0 & the transition that project maintainers can append to their GitHub/Nuget/other Readme's, or at least a URL with concise information about it. This will help quickly get any users of those projects up to speed on WinUI 3.0, and explain what they'll need to do to complete the transition.
5. Outline a suggested transition process and timeline that project/library maintainers can choose to adopt.

In regards to the last item, this should cover such suggestions as:

• Create a new major release number indicating it is to be used with WinUI 3.0 apps (such as WCT v6.0).
• Optionally(?) create a branch to contain the legacy code that will support projects which have not updated to WinUI 3.0 yet.
• Provide a period of time (e.g. 3/6/12 months) over which support for legacy projects will be provided (i.e. merging bug fixes and such from the main branch). This could potentially have specific dates to 'synchronize' the support period across community projects/libraries.

Lastly, I feel it will be important to identify what can be done if you need to support Windows 10 version 1507 & 1607 LTSB. These are the only 2 supported versions of W10 that will be in the wild and that WinUI 3.0 will not be compatible with at release time.

Originally I was going to suggest testing the process out with the Windows 10 Calculator, since it is a production quality open source app. However, I then realized that this app needs to run on 1507 & 1607 LTSB for another 6-7 years. There will obviously be some contention around supporting these types of apps, especially when it comes to smaller community projects. If they really need this support, then a clear long-term strategy for how to do so should be provided.

Regarding WinUI 4.0/3.x/vNext

As the comments here indicate, the community has quite a long wish list for future releases of WinUI. We should really capitalize on the momentum and enthusiasm being built up here by publicly documenting some of the more long-term plans.

Since most of these items are out-of-scope for v3.0, I feel a new issue should be created sooner rather than later to start gathering community feedback on WinUI 4.0/3.x/vNext. If anything, this will help identify both the types of work that the WinUI team is considering, and what is out-of-scope for WinUI and/or the responsibility of other MS teams.

An example of the last point - I'd really like to see these things:

• .NET Core 3.0 support for UWP projects (.NET team's responsibility, as I understand it)
• Full support for Windows Apps (UWP & Win32) from the Visual Studio App Center (obviously not something the WinUI team is responsible for)
• More concrete Fluent Design guidelines, similar to what you can find in the Material Design docs (again, separate team's responsibility)
• Usage of WinUI 3.0 & Fluent design in the in-box W10 apps (separate teams & some of those apps need to support LTSB versions)

By identifying these out-of-scope items we can redirect the community towards the proper points of feedback, and/or otherwise explain what is going on in those areas.

Outside of those things, the in-scope wish list can start coming together, and the community can begin showing their support for what they want the most out of WinUI in the future.

It would great if F# would have an on par support with C#, for example having the same project templates as C#.

I would like that WinUI (UWP vNext) have a proper Window object like WPF had, with Top, Left, Width, Height, StartupPosition, IsTopMost, AllowTransparency, and Show() / ShowDialog() methods.

(_I am not sure about how this Window would work (or be allowed) on small screen devices, like Mobile Phones and IoT_)

@TonyHenrique there's a new windowing API for UWP in 1903, but it's far from finished.

Is looking again at the rendering of XAML within the scope of WinUI 3.0.

Things I feel are a step down from WPF's rendering are:

• Text not using ClearType, instead favouring greyscale anti-aliasing;
• Lack of Pixel Precision for things like border strokes;

I can understand when Windows Phone 7 and Windows Phone 8 had to share a rendering system - the type of screen tech, and speed of rendering were pushing towards being more performant. But with WinUI pivoting to Desktop first, and larger displays - perhaps its time to restore these qualities to the XAML Render engine.

And if things like Hololens and Xbox require special consideration, why not offer a performance mode which can be turned on at the platform level on those devices that need the rendering as it is now?

What about f# template?

Unless it works out of the box in standard Windows Forms and WPF project templates targeting .NET Framework 4.5 or newer, we cannot adopt WinUI library.

Requiring only the latest Windows 10 release and/or UWP application is showstopper for adopting Fluent design.

I would suggest that Microsoft work directly with the Windows Community Toolkit maintainers (some of which work for MS)

@kmgallahan
Great suggestion! This is definitely in the plan. Our team often works closely with Windows Community Toolkit maintainers and it's one of the things we'd like to use as a test project.

Is looking again at the rendering of XAML within the scope of WinUI 3.0.

@mdtauk
Any rendering changes are likely out of scope for 3.0, but please do open an issue for it so we can potentially revisit the idea for subsequent releases. A big focus has definitely been universal performance which as you note led to some rendering changes in Windows 8+. The performance mode switch is an interesting idea.

What about f# template?

@edgarsanchez, @khoshroomahdi
It seems like we're getting a lot of interest in F#! We'd love to hear more about why you want F#: please feel free to comment in the F# issue about why you want it and what you would use it for: #740

Unless it works out of the box in standard Windows Forms and WPF project templates targeting .NET Framework 4.5 or newer, we cannot adopt WinUI library.

@jozefizso
Have you looked into Xaml Islands? This feature lets you use WinRT Xaml in WPF and Windows Forms applications so you can start enhancing them with modern Xaml views/pages:
https://docs.microsoft.com/windows/apps/desktop/modernize/xaml-islands

We're planning for WinUI 3.0 to include islands and to be backward-compatible to Creators Update and newer, which is at least the last 5 versions of Windows.

Could Xaml Islands working on Creators Update and newer with WinUI 3.0 meet your needs?

Any rendering changes are likely out of scope for 3.0, but please do open an issue for it so we can potentially revisit the idea for subsequent releases. A big focus has definitely been universal performance which as you note led to some rendering changes in Windows 8+. The performance mode switch is an interesting idea.

Done #768

XAML Islands require Windows 10, version 1903 and the Windows Community Toolkit library requires the project to be UWP. That's a no go.

XAML Islands require Windows 10, version 1903 and the Windows Community Toolkit library requires the project to be UWP. That's a no go.

WinUI 3.0 wont be going to Windows 7/8/8.1 - but those OSs will reach end of life very soon. And you can still use WPF and WinForms for those for now. This is for when your users have moved to Windows 10

In which case the project will be UWP for Windows 10, so there's no point in supporting WPF/WinForms. This is just moving in a circle and fragmenting the developer tools.

@jozefizso More accurate to say that UWP is changing to allow it to be more like WPF and WinForms, and the XAML UI is getting closer to WPF and WinForms platforms.

UWP apps with modern XAML UI breaking out of the restrictive sandbox, and able to connect into the WPF and WinForms platforms.

This is how I understand it.

XAML Islands require Windows 10, version 1903

In which case the project will be UWP for Windows 10

With WinUI 3.0, we're planning to make islands available on 1703 and up (so much further back).

We're also working toward WinUI being usable with a Win32 app model instead of UWP (informally being called "WinUI desktop"), so it won't necessarily have to be a UWP app.

We're also working toward WinUI being usable with a Win32 app model instead of UWP (informally being called "WinUI desktop"), so it won't necessarily have to be a UWP app.

This is the thing I'm most excited about. A native application with the full API of Windows available, whether that's Win32 or the Windows Runtime, able to have performant UI via Xaml.

We're also working toward WinUI being usable with a Win32 app model instead of UWP (informally being called "WinUI desktop"), so it won't necessarily have to be a UWP app.

This is the thing I'm most excited about. A native application with the full API of Windows available, whether that's Win32 or the Windows Runtime, able to have performant UI via Xaml.

Take a WinForms app, keep the codebehind, but replace the Form with a XAML Window, and have access to all the brushes and XAML Controls.

WPF would be slightly more complicated to just use the WinUI XAML in place - but at least the WPF controls could be styled to match the WinUI ones

1. The namespace should be renamed. "Xaml" is not appropriate because Xaml refers to a markup language, which is incorrectly being used as marketing language (which changes often) for native UWP components. "Xaml" should be replaced with "WinUI". You can see how much confusion is caused even in this thread, where it is very often unclear whether "Xaml" refers to the .xaml language or to ui components.
2. Insofar as this moves WPF and UWP closer together this is good. They each have features not present in the other, and it makes sense to have "Windows UI" that combines the two. There may be some duplication of features but this can also be a transition path WPF -> UWP.
3. Decoupling from windows versions makes sense, but it's also OK to assume a relatively updated Win10, given that Win7 will be well past EOL when this work is finished.

Xaml is the name of the UI framework. Hence Windows.UI.Xaml...

Xaml is the name of the UI framework

Xaml was a technology in WPF that enabled developers to powerfully describe and construct not only scenes of presentation within their applications, but applications themselves. That is, you could describe UI elements _as well as POCOs_. If it was .NET, it could be richly described with Xaml and loaded into an application context.

Lest we forget (and it sounds like we have) that Xaml stands for eXtended Application Markup Language, which means that it is a markup language that enables you to elegantly and efficiently describe .NET _application_ components. While it was primarily used to describe user interface elements, it was not in practice relegated or constrained as such.

I personally ended up using Xaml to describe my entire application configuration, removing and replacing App.config -- and yes, even Web.config -- complexity except in cases for those external APIs that absolutely required it.

Xaml is _not_ UI. They are two totally different concepts altogether but have unfortunately been conflated for years now under UWP. I for one would _love_ to see the term "Xaml" untangled from these efforts, but I am not very confident that such measures would be considered, let alone undertaken.

@charlesroddie I kind of agree the naming is really arbitrary. Just a tangent, if you ever inspect the stack traces of things originating in W.U.Xaml namespace, it's actually internally in a namespace DirectUI. I'd love to know the story of Win8 if anyone here was around during those days, because I imagine there was a different story. DirectComp for compositing layers, DirectManipulation for smooth scrolling and rubber banding, and then Direct2D/DirectWrite as the vector graphics engine with DirectUI on top to pull it all together. Then for some reason, some of it was back ported to Win7, only the Xaml bits got exposed through the WinRT system, while all the other APIs were left as cryptic com interfaces with weird factories and patterns that you needed to see samples explain how to invoke.

Actually, now that I think about it, it'd be really nice if, just like W.U.Composition exposed DirectComp and DirectManipulation through WinRT (or is it a rewrite), Direct2D/DirectWrite had a formal home here as well. They all work together to enable various levels of escape hatches and touch points of fidelity if you're looking for it. Win2D is really half baked and not a good API either.

Windows.UI.Composition is a re-write of DirectComposition I believe. The APIs are similar but not the same.

Stop assuming all monitors are sRGB anymore.
Treat all legacy apps' colors as sRGB and do conversion for each monitor during composition.

This might be a little off-topic, but assume you already have a large Win32 appliation written in C++, you want to modernize the UI system, so you may want to use WinUI or Comp with minimal dependency, like use Comp only without in-box control set, or even without XAML.

That’s already possible now though, we don’t need to wait for WinUI 3.0 for that.

Thanks all for the feedback on naming. As noted we do have a distinction today between the "Xaml platform" and "Xaml language" (with its own different specs/dialects) which can get confusing. I don't think a major rebranding is in the cards but we're definitely discussing naming and namespaces.

Use Windows.UI.Composition in a C++ Win32 application without XAML for modernizing existing applications (like Photoshop). They already have a UI architecture.

This might be a little off-topic, but assume you already have a large Win32 appliation written in C++, you want to modernize the UI system, so you may want to use WinUI or Comp with minimal dependency, like use Comp only without in-box control set, or even without XAML.

Thanks for the feedback on this - I think this should hopefully be possible in the end with WinUI 3, similar to a "frameworkless" app using Windows.UI.Composition which you can already do today. We'll keep this in mind as we determine how to structure the WinUI NuGet package(s) and dependencies.

Stop assuming all monitors are sRGB anymore.
Treat all legacy apps' colors as sRGB and do conversion for each monitor during composition.

@reli-msft could you open a separate issue to track that?

@jesbis 👉 #67

Apple today announced SwiftUI...

How about if Xaml Direct were to be given Visual Studio templates to enable developers to choose to make apps using code instead of XAML and code behind.

I don't think a major rebranding is in the cards but we're definitely discussing naming and namespaces.

Thank you @jesbis I appreciate you being so engaging in this thread. Usually, it seems that someone will make a post/announcement like this and then leave it for dead (or for others to sparsely manage), so it's encouraging to see that you as the thread author are not only being engaged but also being attentive to what others are saying. Especially when those others is _me_. 😆

And you are right: there's the 1) user interface platform and 2) the language/markup/description mechanism. In my critical remarks, I will say that I never give enough credit for the (first) user interface platform, as I know there's been a lot of great work by the Windows team around this. That's never been a point of concern as for me, personally. It's the 2nd area that draws my (and others') ire and consternation, and we see this in the UserVoice issues that have cropped up over the years.

All this said I would at least ask (beg, even 😅) to further consider branding efforts to better categorize these two spheres. I think "Xaml Direct" is the pinnacle of confusion here, as its name implies "Markup Language" -- it's right in the name! -- but there is nothing of the sort in its actual usage. Terribly confusing and misleading, and borderline abuse of brand, I would offer.

And speaking of Xaml Direct, @mdtauk:

How about if Xaml Direct were to be given Visual Studio templates to enable developers to choose to make apps using code instead of XAML and code behind.

As in something like CSharpForMarkup?

A much better and apt name than Xaml Direct, I would suggest. Of course, _any_ name would be. 😉

And speaking of Xaml Direct, @mdtauk:

How about if Xaml Direct were to be given Visual Studio templates to enable developers to choose to make apps using code instead of XAML and code behind.

As in something like CSharpForMarkup?

A much better and apt name than Xaml Direct, I would suggest. Of course, _any_ name would be. 😉

@Mike-EEE https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

It is designed for middle-ware to write XAML UI from code, but what if there were templates to use it instead of XAML files? Just a thought to put out there...

@mdtauk YES! SwiftUI kind of looks like Xaml but done in code. I really love the idea of everything in code the way React does it. It's sort of old school to break up your design files and then link with some kind of code-behind, and I find it makes it hard to maintain.

A friend was just mentioning that they need the SwiftUI layout engine to work with the iPad Pro's 120hz display. So that's what they've been focused on. Quite fascinating really.

I made a new issue #804 where discussion about SwiftUI inspired changes could go @eklipse2k8

Please DON'T FORGET to add templates for Visual Basic.😀

Let WPF to built _on_ WinUI 3‘s lower layers!

@reli-msft what benefits would you want to get from updating WPF?

If there are specific WPF features you rely on which you would like to see in WinUI then we'd love to hear more in the "WPF features that should be in WinRT [WinUI]" thread: https://github.com/microsoft/microsoft-ui-xaml/issues/719

Closing in favor of new pinned issue #888

Really looking forward to this. Will solve many issues specially version related.

@weitzhandler [on May 16 2019

To me, all the technical details are less important.
UWP, WPF or any Windows-only framework, as awesome as it would be, isn't going to be enough so long it doesn't run on every platform (at least Windows, Droid, iOS and web), and is friendly with any screen size.

As per WinUI and XAML in general, I'd love to see improvement in the following aspects, some of which I find annoying and slowing down my work.

• A LOT more built-in converters There should be a ton of converters, some of which should even be used as a markup extension to reduce verbosity. This should also include negating simple arithmetic action, object to boolean converter (false by semantic value, i.e. empty string, empty collection, hidden visibility etc. per context).
• Same as above but with behaviors. There should be an easy port between binding and events/actions. Would be much easier if that would have been built-in and not have the dev live in doubt which non-tested NuGet to use.
• All missing stuff from WPF, such as some binding types, markup extensions, generic views and others.

Thank you!

A LOT more built-in converters

Since Babbage's analytical engine, and Turing's theory of universal computation, it has been possible for a single computer which can run any program that any computer can run. You want to go back to a time when we have to create a new computer for every calculation you want to do.

The whole converters business should be unceremoniously dumped.

object to boolean converter

booleans are booleans. Other objects are not booleans. And there is no natural conversion from objects to booleans. Types are important in .Net and further untyped systems should not be exposed to users.

Yes and existing untyped systems like bindings should be dumped too.

The whole converters business should be unceremoniously dumped.

I mean what are your alternatives?
My pain point with converters is only that you have to re-write them yourself / choose from NuGet, and that they're so verbose. That in addition to them being non-flexible allowing no expressions such as arithmetic or negation etc.

booleans are booleans. Other objects are not booleans.

You're right, but when it comes to UI, it doesn't really matter.
You wanna show/hide stuff based on conventional state of object. Not everything should have a dedicated visibility property.

existing untyped systems like bindings should be dumped too.

Huh? I actually think it has an advantage. Loose-coupling between V and VM can be good.

existing untyped systems like bindings should be dumped too.

Loose-coupling between V and VM can be good.

For small projects maybe, but there are better abstractions for loose coupling than literally turning off the compiler assistance. If you ever had to maintain a large application with dozens to hundreds of views and want to refactor something which may be used in multiple sites, not having the compiler verify correctness of binding paths is a major degradation in developer experience. There is a reason why we have type systems in our languages, large projects are literally unmaintainable without tools to assist the programmer, currently UI languages are lagging behind a lot.

Compiled bindings help a lot for that.

@weitzhandler I mean what are your alternatives?
... Not everything should have a dedicated visibility property.
Huh? I actually think [bindings] has an advantage. Loose-coupling between V and VM can be good.

In a good reactive framework you can define observable variables (in code) like name:Mutable<string> and then map them to let visibility = name.map(fun s -> s <> "") and then bind them to view properties with visibility.bind someView.set_IsVisible or name.bind(fun s -> someView.IsVisible <- s <> "").

I use https://github.com/ReedCopsey/Gjallarhorn but there are various reactive frameworks around.

Note that: 1. everything is typed, unlike bindings. 2. Things (functions, properties, views) are referred to as objects, not by passing string names around, 3. functions are just functions, much less clunky than converters, 4. binding boilerplate, where simple object properties need to be given extra "bindable properties" etc., can be removed.

Views can still be written in Xaml, especially if they are simple mostly static layouts, with the disadvantage of magic strings everywhere, but the advantage of having a designer to give a live view. Better would be to have code which gives a live view. Very possible with an interpreter.

Speaking of reactive frameworks, please check out Chain Reactive and tell if I should open source it.

Hi, can ms team solve all the bugs/features on uservoice?
If did, that would a great step, more than WinUI 3.0.

@hupo376787 I think you got downvotes because this isn't the thread to discuss the windows development platform more broadly, and even this repo is likely not the right place either as it focuses on just one aspect of this platform.

But it IS a problem that there is no place for open discussion of windows development platforms that microsoft and developers can take part in, and it IS a problem that the relevant microsoft group does not maintain any feedback mechanisms, having not updated or responded to that uservoice for several years.

@charlesroddie Yeah, it seems user voice is abandoned. I'll send my voice to Feedback Hub. Perhaps ms will ignore them, but I'll do my job.

The UserVoice is being fully retired this month.

For specific products, GitHub repos (like this one) are the best place for feedback since the relevant engineering teams are actively using them.

For feedback that isn't related to a specific repo's product, please do use Feedback Hub. There is a "Developer Platform" category with various subcategories specifically for feedback on APIs and developer tools.

I know there's a lot of history and previous feedback currently on UserVoice (which we'll still keep track of), but both GitHub and Feedback Hub provide a more direct path to our engineering teams and workitem tracking than UserVoice ever could, so hopefully this should be a positive change. We're in the process of updating various support and feedback links.

We do see everything that comes in from either channel and really do appreciate feedback and bug reports!

@jesbis OK, got it.

For WinForms, when using the new WinUI project template, will the Properties Window still work and be able to set the properties of the WinUI controls? I can code HTML all day long no problem (Asp.net MVC usually), but when there are so many settings available for controls, I've enjoyed using the properties window for the last 20 years.

@Dean-NC I guess that you are asking about the XAML designer, no WinFoms/Windows Forms, right? If so, yes, the Properties Panel will still work for WinUI controls when you select an item on the XAML designer.

@marb2000 I guess I naively thought that WinUI 3 would bring the new controls to WinForms in the sense that it would be mostly seamless, and that I could have a form with both legacy and WinUI controls on it, and that the Properties Window would work for both legacy and WinUI controls.

I read the entire posting above, and I've been following this with much excitement (as a WinForms developer), but I guess I've misunderstood the high-level workflow of how this will work (again, from a WinForms point of view).

I've said for a long time that WinForms could still be a great thing for years to come, but it's biggest weakness is that its basic controls look dated (textbox won't allow padding, so it looks skinny, small radio and checkbox buttons, etc.). Just the very basics of Win 10 controls (textbox, radio, checkbox) would go a long way to bringing new life to WinForms.
Is there some article, or do you mind giving a brief description of how the workflow would be for a new WinForms project that wants to use both legacy controls and the new ones?
Thanks.

@marb2000 I guess I naively thought that WinUI 3 would bring the new controls to WinForms in the sense that it would be mostly seamless, and that I could have a form with both legacy and WinUI controls on it, and that the Properties Window would work for both legacy and WinUI controls.

I read the entire posting above, and I've been following this with much excitement (as a WinForms developer), but I guess I've misunderstood the high-level workflow of how this will work (again, from a WinForms point of view).

I've said for a long time that WinForms could still be a great thing for years to come, but it's biggest weakness is that its basic controls look dated (textbox won't allow padding, so it looks skinny, small radio and checkbox buttons, etc.). Just the very basics of Win 10 controls (textbox, radio, checkbox) would go a long way to bringing new life to WinForms.
Is there some article, or do you mind giving a brief description of how the workflow would be for a new WinForms project that wants to use both legacy controls and the new ones?
Thanks.

More likely that you will be able to take your app project, add WinUI windows and pages, and use the modern XAML UI to replace your UI either totally, or bit by bit.

And there are XAML Islands for inserting XAML into existing Winforms and WPF UIs

You Blazor team should work with Uno to get some of its hosting models included in Uno (in particular the server side), and/or to get the Uno UI (and thus WinUI 3) rendering/visual layer useable by Blazor....and/or maybe Xaml Islands for Blazor ?

I feel a little out of it here because most of the feedback comes from devs who work primarily in the xaml space. They generally seem to be looking for a better version of what they've got already. That might be good for existing users but I don't know if it will pull in many devs who have shunned UWP to date.

My team has developed only 1 UWP app. We won't be developing any more.

The insurmountable hurdle is the lack of a built-in tabulated report writer. We've tried all of the 3rd party report writers on the market that say they support UWP. Unfortunately none of them works well with UWP. Their UWP offering is usually a quick hack of their WPF/WinForms variant and won't work properly.

We use Stimulsoft Reports in our UWP product. It is very buggy and they have told us that they won't be fixing the bugs as their UWP uptake is so low.

I see you have data visualisation on the list. But the reason there are millions of battleship grey apps still out there is that many businesses don't care much about the visuals for internal apps. They want columns of numbers with sub-totals.

So if WinUI is meant to finally lure the forms over data devs, then we need a built-in tabulated report writer.

I hope this doesn't offend the visual people :-)

I agree fully. How can we develop modern business apps without a reporting system that can be easily integrated with the app? it is a massive canyon that will stop developers moving over.

Business users need to be able to interact with tabulated data and then print it or export it into other formats. They also need to be able to create Invoices, quotes, statements and other instrumental documents.

It's my understanding that business/ enterprise is still the biggest consumer of Windows. Why is something so fundamental to the Windows ecosystem not being developed for UWP?

Thanks for the feedback @VagueGit and @Elmarcotoro ! Enterprise controls are a gap for us right now. But your timing is good, we are collecting feedback for the design of a DataGrid control. Please read and give feedback over here: #1500 .

Likewise, beside square tabular data control, we need an opensource UWP graph control to creatively in democratise way share complex relationships through diagram control

For a reporting system, I think Telerik UI is the best choice currently. A Chinese proverb saying "Some people specialize in some professions while others in other professions.". Telerik, or DevExpress or someone else, are good at reporting.

For the lack of various controls, we should not blame this team, but for the whole MS strategy. From the beginning of Satya abandon mobile, they prefer ios & android better, cause boss like them. The whole UWP ecosystem becomes weak and weak.

For now, there is a arguement named "UWP is dead" on twitter, I think MS should clarify this and declare their uwp road.

For now, there is a arguement named "UWP is dead" on twitter, I think MS should clarify this and declare their uwp road.

You’ve just posted that on the roadmap thread...

@jevansaks Thanks for the info on the Datagrid control. This does not deal with the issues of printing reports and pagination, exporting and such. These are real life business scenarios that need to be dealt with, not whether some button animates (as nice and as cool as this can be).

@hupo376787
"For a reporting system, I think Telerik UI is the best choice currently."

From what I can see Dev Express are the only ones who currently provide a full stack for creating and viewing reports for UWP, and their pricing seems to be on the premium side. All the others including Telerik have gaps in their tooling which means reports for UWP cannot be created. I'm willing (hoping) to be corrected on this.

For a reporting system, I think Telerik UI is the best choice currently. A Chinese proverb saying "Some people specialize in some professions while others in other professions.". Telerik, or DevExpress or someone else, are good at reporting.

@hupo376787 please take extra care to check your facts before implying a posting is incorrect. Telerik Reporting has a report designer for WPF and WinForms but not UWP.

DevExpress also has a report designer for WinForms and WPF, but not UWP

So please check your facts before committing yourself to an error that will be preserved in perpetuity and circulated widely. Hey that sounds like it might be an old proverb one day 😉

@hupo376787 please take extra care to check your facts before implying a posting is incorrect. Telerik Reporting has a report designer for WPF and WinForms but not UWP.

DevExpress also has a report designer for WinForms and WPF, but not UWP

So please check your facts before committing yourself to an error that will be preserved in perpetuity and circulated widely. Hey that sounds like it might be an old proverb one day 😉

OK, I think we have the different understanding of Reporting. I mean https://www.telerik.com/universal-windows-platform-ui and https://www.devexpress.com/products/net/controls/win10apps/.

I was incorrect, Dev Express do not provide reporting for UWP. It appears no third party tooling developer does! I contacted Dev express through their chat, about whether they had a road map for providing reporting for UWP.
They said,
"The XtraReports Suite uses the functionality provided by the System.Drawing assembly and the thing that prevents us from implementing the same set of tools for Universal Window Applications is that this assembly isn't available there (https://stackoverflow.com/questions/31545389/windows-universal-app-with-system-drawing-and-possible-alternative). So, we haven't yet established our future plans in this area."

@jevansaks, it seems there is a lack of communication between the Microsoft UI team and these third party tool providers. We would be happy to use third party tooling, but it looks like the UWP platform makes it difficult for these companies to integrate the tooling they have for other platforms into UWP.

They asked me to contact their [email protected] with our reporting requirements, it may be helpful for the Win UI 3.0 team to get in contact with them and see if their is a way to assist them in implementation. I don't see how you will get business devs on the universal platform without proper reporting tools.

https://www.devexpress.com/subscriptions/reporting/

Reporting: just from a WinForms perspective, I've used both Telerik and DevExpress (even their latest versions), and while Telerik was good, I think DevExpress not only has a better overall designer and experience, but has a lot more subtle features that allowed me to do more complex layouts than Telerik. I think the DevExpress rendering technology is more advanced.

it may be helpful for the Win UI 3.0 team to get in contact with them and see if their is a way to assist them in implementation.

Thanks for the call-out. We'll reach out to them as well.

Thanks for the call-out. We'll reach out to them as well.

It may be worth talking with all of them and seeing what the blocks are? Telerik, Grapecity, DevExpress etc.

Thanks for the call-out. We'll reach out to them as well.

It may be worth talking with all of them and seeing what the blocks are? Telerik, Grapecity, DevExpress etc.

For sure, that's our plan.

We're a bit different than most developers building for Windows. We develop mostly kiosk apps (apps intended to be run by users other than the computer's owner, and typically full-screen without any access to the broader system). The apps are generally built to the specific requirements of the customer, with no intention to distribute them through the store or equivalent.

Because the apps run full-screen, there's very limited value in the built-in controls maintaining the look and feel of other Windows apps; instead they tend to be highly branded for each customer. We do still need a lot of common _behaviour_ and controls from standard Windows apps, but we typically do a lot of customisation of each one's control templates or at least override their core styles. For a very long time we built a lot of apps as WinForms backends with embedded Flash frontends for UI.

Broadly speaking almost every app we write integrates some kind of web-based backend with some piece of hardware (e.g. a printer, a barcode scanner, a mag stripe reader, an RFID scanner, a camera, card payment hardware, vending-style cash payment components, etc.), and the vast majority of those components historically have come with Win32 SDKs and not UWP ones.

For those two reasons, most of our historical apps are WinForms apps, and most of our modern apps are WPF ones. We have built a few UWP apps (largely to benefit from the really nice Assigned Access/Kiosk mode capabilities of Windows), but they're typically a pain to work on compared to WPF, and we typically can't get compatible hardware SDKs anyway.

We are very much intrigued by XAML Islands though, to allow us to write Win32-compatible apps with modern UI (although the advantage of UWP over WPF to us is not always clear, especially if we're not using standard controls or Microsoft-specific effects like Fluent, etc.).

To answer your specific questions:

What templates would interest you most?

C# with .NET Core, Win32 with WinUI 3.0 overlaid would be nice.

Were you aware of Xaml Islands for modernizing desktop apps?

Yes, and I was relatively happy with them when I've played with them, although we're not likely to use a _single_ control, so much as making a decision for the whole custom UI.

The main reason I was aware of it was because we'd get Lottie support for Win32 apps.

Does this expanded backward-compatibility on Windows 10 make Xaml Islands more useful to you?

Not really; we almost always control the target PCs and can ensure we're always getting the latest compatible release.

Would it help if Visual Studio or another tool automatically updated namespaces for you?

Yes.

How important to you is full compatibility between existing UWP Xaml components and WinUI 3.0 apps?

Very minimal. The main compatibility headache we'd have would be changed StaticResource keys for styling core elements.

Do you create or use UWP Xaml control libraries or WinRT components that you couldn't easily recompile and update alongside app code?

Yes, we have used the Syncfusion UWP control library in the past.

What would be your preferred solution for using UWP Xaml components with WinUI 3?

The preferred solution would be to have more standard controls available in WinUI itself rather than leaning on outside sources (e.g. document viewers), but I expect those external component libraries would typically be more progressive about updating their libraries than we'd be at switching to WinUI 3 anyway for the most part.

What do you think about the overall 3.0 plan outlined above and in the roadmap? Would it enable you to use WinUI for your new and existing Windows apps?

I'm excited to see UWP controls being more clearly decoupled from the UWP app and security model that has historically locked us out due to hardware compatibility reasons, especially since WinUI is being designed and developed in the open.

With such clear guidance about how Microsoft recommends us to build app UIs, I would expect all our apps would end up with WinUI frontends, regardless of which backend we can support.

What kind of apps would you be most excited to use WinUI 3.0 for? Creating a new Win32 app and packaging it with MSIX? Adding new views to a WPF app? Modernizing a C++ MFC app with Fluent UI?

Mostly about getting access to more actively-maintained libraries of controls in my older apps, with nicer, more obvious documentation (or even access to the underlying code for the standard control) makes it much easier to figure out when I can adapt a standard control and when I need to roll my own user control. For example, in a recent app built in WPF I had a couple of date pickers; getting that control to work nicely for touch, and customising the size, font, pop-up icon, etc. was extremely annoying. I'd be inclined to use WinUI for that sort of app by _default_ in the future given the roadmap above, because:

1. I can be reasonably assured that there is a native date-picker control that is at least moderately touch-friendly
2. I can examine that control's native/out of the box templates, etc., easily to see what I need to override to get it to match the design proofs for the customer's look-and-feel (as a roughly representative example, I might want to figure out the cleanest way to style the type—font size, weight, family—of a TextBox control's Header independently from its input text; does the standard HeaderTemplate use magic static resources I can redefine or do I need to override the template itself? If I do override the template, what's the default template's markup look like; does it do/support anything I hadn't considered?).

I see that this has been closed, but there are a couple of issues that get raised by our users which I though would be worth raising. They are productivity improvements for users who work with large amounts of data.

TextBox:
If a user needs to edit a TextBox they first have to click in the TextBox to display the clear button and then click the clear button to clear the TextBox. This is very inefficient when working with large amounts of data. It would be good if when the users clicks or tabs into the TextBox the text could be highlighted ready to be written over.

Gridview/ ListView:
The Gridview and ListView do not seem to allow the user to effectively Tab through the collection.
The ListView does allow Tab to move to controls on the same row, but it will not Tab to the next row of controls. Instead the ListView loses focus and Tab moves onto the next control in the visual tree.

These are two issues raised by our users as very annoying.

@Elmarcotoro

I'd recommend that you create a new issue for each of the improvements you mentioned. The WinUI team will then triage to determine if they'll require WinUI 3 to be released before implementing or not.

This issue existed primarily to garner feedback regarding the 2 "General Questions" at the top of the post.

Support the Blazor hosting model native in WinUI. This would allow a Blazor control to be used directly in Client/Server web, or used directly in WinUI. The Blazor roadmap has this future concept without using a WebView control. This way the control's UI runs native with the .Net Standard portion of the code also running native.

Support the Blazor hosting model native in WinUI

Discussed on the Blazor side, FWIW:
https://github.com/dotnet/aspnetcore/issues/11082

For sure, that's our plan.

@jevansaks Would be great to get into the loop as well.

I'd like better consistency of Tray Menus / Icon Menus with WinUI 3.0. Every App has a different spacing, and Win32 apps do not follow the font rendering / spacing / themes consistently. Please fix this already!

WinUi in desktop completely useless for me due to lack of any windows management possibility: show/hide windows, windows position, windows size, dock/undock ...

@alexandrevk it is still a preview. Did you see the windowing API design? https://github.com/microsoft/ProjectReunion/issues/157

Thank you @dotMorten for linking to the windowing announcement post!

@alexandrevk - we are putting together APIs for Reunion that will allow you to do these type of windowing operations from both Win32 and UWP with WinUI content as well as when using other frameworks/swapchain content in your window. Some of these windowing features may then be abstracted into the WinUI window class for easier access as well, but that is further down the road. Feature specs for the windowing area are in the pipe, stay tuned.

Speaking strictly as an invidual user (ie: non-corporate/company) and c++ only, even if i am just a lone voice shouting into the void, i feel the need to say, that as long as any of these new UI systems are tied to UWP and that horrible packaging system they build into, then i'm afraid it will always be in the dark whatever you do. (Speaking from WinRT experience, havn't tried WinUI yet but it looks pretty much the same to me).
Surely it must be known that little to noone actually uses UWP apps? (actually hated by most afaik) so if its going to be called 'native' then why isnt it truly 'native', ie: a few #includes, link a .lib or two and build your app in STANDARD c++.
Having to resort to things like Qt when cross-plat is of no concern, just to avoid wrapping win32 for the 1000th time is getting kinda old to be fair.
Anyway just my 2cents, from someone who uses the language every day, but probably has no place commenting here.

@nl-n you should be happy to know that one of the big deals with WinUI is that it doesn't require to run as a UWP app. In fact this has been possible since preview 2.
_Currently_ it does require packaging as msix, but msix is actually a pretty decent way to distribute (and update) your apps.

@dotMorten That's one of the big issues: requiring side-loading/installing via the store. i don't know a single person who doesnt disable/strip the store before (or just after) installing windows, so how are we supposed to distribute them?.
I know that's somewhat rhetorical but it serves the point. I should just be able to zip up the build directory and distribute it (or an installer if warranted).
Then there's the compatibility issue, a great many people still refuse to even install W10, so there's that too...
It is good however to hear that's the direction 3.0 is heading though, as much as i hate xaml, it would be a welcome addition.
Maybe we could get it without needing to install the whole 50gb UWP workload in VS too? 🙏 (exaggerating i know, but still)

To quote @MarkIngramUK near the beginning of this thread:

It's 2019, I want a fast, native UI, and I don't want to have to seriously consider making a user interface with CreateWindowExW, GDI, etc.

which (funnily enough) i am literally having to do right now, and yes it is just as painful as it sounds :)

@nl-n who said anything about the store? MSIX isn't really different from installing from MSI. It's just an app installer. Double click it to install. No store needed. Guarantees a 100% clean uninstall too (as opposed to MSI which makes a giant mess)

i don't know a single person who doesnt disable/strip the store

It's not common though.

how are we supposed to distribute them

First of all, you need to inform users to not disable the store)

I should just be able to zip up the build directory and distribute it

MSIX can be installed without a store. With latest Windows versions user don't need to enable anything for that. Of course if package was signed before with trusted certificate. But yeah, if user removed store from the PC, then he could also remove MSIX/APPX AppInstaller from it as well. In that case they probably don't want all variability of applications.

a great many people still refuse to even install W10,

It's their choice. Nuff said.

whole 50gb UWP workload in VS too

Single SDK is about 3GB. It isn't required to download every one starting 10240 one.

@nl-n who said anything about the store? MSIX isn't really different from installing from MSI. It's just an app installer. Double click it to install. No store needed. Guarantees a 100% clean uninstall too (as opposed to MSI which makes a giant mess)

That was from the description visual studio gives you, 'for sideloading/installing via the microsoft store', the only other information i've found on msix is from the msdn, which basically says: msix packages are sandboxed/virtualized 'appx' applications, which is pretty much a killer for anything working directly with the winapi. And they require signing to even be installable?...

It could also just be crossed wires i suppose, too much differing teminology, and i don't know much about UWP.

It's not common though.

More common than you think, and with reason 😄

Anyway, it wasn't my intention to derail, so i'll go back to writing my CreateWindowExW stuff for now 🤣