WinUI 3.0 roadmap - we need your input!

[jesbis]

WinUI 3.0

At the Microsoft Build conference in May 2019 we shared our plans for WinUI 3.0, which will greatly expand the scope of WinUI to include the full native Windows UI platform. This means that the full Xaml framework would be developed on GitHub and ship out of band as NuGet packages.

The WinUI roadmap is now up to date with the latest plans for WinUI 3.0:
https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md

You can also watch the Build 2019 conference session State of the Union: The Windows Presentation Platform for more details.

We'd love to hear what you think, and have some specific questions below.

How will this affect building Windows apps and components?

WinUI 3.0 will provide many benefits compared to the UWP Xaml framework, WPF, WinForms and MFC.

So, we want to make sure it's easy for everyone to use WinUI 3.0 in new and existing apps. There are a few ways we can approach this, and we'd love to hear your feedback on what areas we should focus on.

Our current thinking is:

Creating a new app

We plan to create new Visual Studio 2019 project templates for common languages (e.g. C# using .NET Core, standard C++17 using C++/WinRT) and app model + packaging (UWP + AppX, Win32 + MSIX).

What templates would interest you most?

The developer experience would be similar to current UWP apps.

Adding WinUI 3.0 to existing Win32 apps

WinUI 3.0 will include Xaml Islands, which let you use WinUI Xaml in your existing WPF, Windows Forms, and C++ Win32 applications.

The current version of Xaml Islands is only supported on Windows 10 May 2019 Update (1903), but the WinUI version should be backward-compatible to Creators Update (15063).

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?

Updating your existing UWP Xaml app to WinUI 3.0

You'll have to update your app's target version to WinUI 3.0 to take advantage of it, similar to retargeting to a newer UWP SDK today.

We want to maximize compatibility between UWP Xaml and WinUI 3.0, but there will be some things to be aware of when updating.

1. Namespace update

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

Old namespace	New namespace (tentative)
Windows.UI.Xaml	Microsoft.UI.Xaml
Windows.UI.Composition	Microsoft.UI.Composition
Windows.UI.Input	Microsoft.UI.Input

We're exploring options for helping you automatically update namespaces when retargeting your UWP app to WinUI 3, at least for .NET apps.

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

2. Mixing UWP and WinUI Xaml components

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

• UWP Windows.UI.Xaml.UIElement and Windows.UI.Composition.Visual elements

with:

• WinUI 3.0 Microsoft.UI.Xaml.UIElement and Microsoft.UI.Composition.Visual elements

in the same app.

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.

We hope that all UWP Xaml control libraries can be updated to WinUI 3.0, but we know that even in the best case it would take time for everyone to update.

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

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

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

General questions

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?

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

[mdtauk]

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.

[paulio]

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

[simonferquel]

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.

[simonferquel]

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!

[GeertvanHorrik]

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.

[wbokkers]

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

[meir-pletinsky]

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)

[shaggygi]

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:

[weitzhandler]

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 its loyal .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!

[TonyHenrique]

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

[huoyaoyuan]

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.

[mdtauk]

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

[anthcool]

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.

[mdtauk]

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.

[simonferquel]

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

[mdtauk]

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.

[lhak]

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.

[jesbis]

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.

[Pinox]

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#

[mrlacey]

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.

[riverar]

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

[jesbis]

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

[jesbis]

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.

[TonyHenrique]

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.

[marb2000]

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

[eklipse2k8]

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.

[mdtauk]

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

[bchavez]

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.

[MarkIngramUK]

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.

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

[meteorsnows]

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.

[RyoukoKonpaku]

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.

[eklipse2k8]

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

[marb2000]

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

[MarkIngramUK]

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

[mdtauk]

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

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

[meir-pletinsky]

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

[mdtauk]

@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

[MarkIngramUK]

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

[eklipse2k8]

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

[TonyHenrique]

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.

[wjk]

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!

[mdtauk]

@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

[thomasclaudiushuber]

@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

[pag3]

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

[mfeingol]

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.

[natemonster]

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.

[kmgallahan]

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

[mrlacey]

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

[mrlacey]

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.