Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WinUI 3.0 roadmap - we need your input! #717

Closed
jesbis opened this issue May 16, 2019 · 174 comments

Comments

@jesbis
Copy link
Member

commented May 16, 2019

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:

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?

@msft-github-bot msft-github-bot added this to Needs triage in Controls Triage May 16, 2019

@jesbis jesbis pinned this issue May 16, 2019

@jevansaks jevansaks moved this from Needs triage to Approved in Controls Triage May 16, 2019

@jesbis jesbis added the discussion label May 16, 2019

@jesbis jesbis changed the title WinUI 3.0: roadmap update and community questions - we need your input! WinUI 3.0 roadmap - we need your input! May 16, 2019

@mdtauk

This comment has been minimized.

Copy link

commented May 16, 2019

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

This comment has been minimized.

Copy link

commented May 16, 2019

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

@simonferquel

This comment has been minimized.

Copy link

commented May 16, 2019

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

This comment has been minimized.

Copy link

commented May 16, 2019

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

This comment has been minimized.

Copy link

commented May 16, 2019

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

This comment has been minimized.

Copy link

commented May 16, 2019

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

This comment has been minimized.

Copy link

commented May 16, 2019

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

This comment has been minimized.

Copy link

commented May 16, 2019

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 😄

@weitzhandler

This comment has been minimized.

Copy link

commented May 16, 2019

To me, all the technical details are less important for now.
The real issue is that UWP or WPF (haven't used WinForms since the release of 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 I got very disappointed on the last build to hear 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 .NET stack devs.

TL;DR I'd want to see MS officially embracing and supporting Uno, or any similar solution, with templates, tooling, and integrated support.

And BTW, I have been working with XF since its acquisition, and wish it had an alternative, for these 3 reasons: a. No web support, b. Very mobile biased, no love for desktops c. A messed up library hierarchy, definitely when compared to WPF/UWP control-library d. Not even real XAML.
Hence, my request to Microsoft: .NET UI Standard.

As for the templates, I'd like to see a template wizard like WTS, but the ideal template to me would be such that provides a solution of an ASP.NET Core Web API backend and a responsive Prism MVVM client with basic menus, identity, and layout functionality that interacts with the server, that works at least on Windows, Droid, iOS and web and wishfully also on OSX and linux, and adapts to any screen size to get me started with the actual development of my project instead of wasting a lot of time on the project structural code.

Thank for all!

@TonyHenrique

This comment has been minimized.

Copy link

commented May 16, 2019

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

This comment has been minimized.

Copy link

commented May 16, 2019

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

This comment has been minimized.

Copy link

commented May 16, 2019

@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

This comment has been minimized.

Copy link

commented May 16, 2019

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

This comment has been minimized.

Copy link

commented May 16, 2019

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

This comment has been minimized.

Copy link

commented May 16, 2019

@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

This comment has been minimized.

Copy link

commented May 16, 2019

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

This comment has been minimized.

Copy link

commented May 16, 2019

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

This comment has been minimized.

Copy link
Member Author

commented May 16, 2019

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.

@charlesroddie

This comment has been minimized.

Copy link

commented Jun 1, 2019

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

This comment has been minimized.

Copy link

commented Jun 1, 2019

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

@Mike-EEE

This comment has been minimized.

Copy link

commented Jun 1, 2019

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.

@eklipse2k8

This comment has been minimized.

Copy link

commented Jun 1, 2019

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

@MarkIngramUK

This comment has been minimized.

Copy link

commented Jun 1, 2019

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

@reli-msft

This comment has been minimized.

Copy link

commented Jun 3, 2019

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

@reli-msft

This comment has been minimized.

Copy link

commented Jun 3, 2019

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.

@MarkIngramUK

This comment has been minimized.

Copy link

commented Jun 3, 2019

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

@jesbis

This comment has been minimized.

Copy link
Member Author

commented Jun 3, 2019

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?

@reli-msft

This comment has been minimized.

Copy link

commented Jun 3, 2019

@jesbis 👉 #67

@mdtauk

This comment has been minimized.

Copy link

commented Jun 3, 2019

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.

@Mike-EEE

This comment has been minimized.

Copy link

commented Jun 3, 2019

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

@mdtauk

This comment has been minimized.

Copy link

commented Jun 3, 2019

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

@eklipse2k8

This comment has been minimized.

Copy link

commented Jun 3, 2019

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

@mdtauk

This comment has been minimized.

Copy link

commented Jun 4, 2019

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

@Berrysoft

This comment has been minimized.

Copy link

commented Jun 5, 2019

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

@reli-msft

This comment has been minimized.

Copy link

commented Jun 10, 2019

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

@jesbis

This comment has been minimized.

Copy link
Member Author

commented Jun 11, 2019

@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: #719

@jesbis

This comment has been minimized.

Copy link
Member Author

commented Jun 21, 2019

Closing in favor of new pinned issue #888

@jesbis jesbis closed this Jun 21, 2019

Controls Triage automation moved this from Backlog to Closed Jun 21, 2019

@msft-github-bot msft-github-bot moved this from Closed to Needs triage in Controls Triage Jun 21, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.