search

microsoft / microsoft-ui-xaml

WinUI: a modern UI framework with a rich set of controls and styles to build dynamic and high-performing Windows applications.
MIT License
6.38k stars 683 forks source link

WinUI 3.0 roadmap - we need your input! #717

Closed jesbis closed 5 years ago

jesbis commented 5 years ago

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:

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 commented 5 years ago

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

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

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

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

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

weitzhandler commented 5 years ago

@jesbis @terrajobst @jevansaks

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

MarkIngramUK commented 5 years ago

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

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

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

galvesribeiro commented 5 years ago

Ok then...

/me keep working on FluSharp

Mike-E-angelo commented 5 years ago

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

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

mdtauk commented 5 years ago

with the following paragraph

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

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

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

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

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

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

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

GiorgioG commented 5 years ago

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

Happypig375 commented 5 years ago

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

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

Re: F#

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

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

jesbis commented 5 years ago

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

Please feel free to direct F# discussions there.

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

jesbis commented 5 years ago

RE: cross-platform UI:

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

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

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

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

bchavez commented 5 years ago

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

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

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

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

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

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

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

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

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

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

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

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

Just like WSL did for running Linux on Windows.

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

Just my two cents. :moneybag:

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

zezba9000 commented 5 years ago

@bchavez

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

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

mdtauk commented 5 years ago

RE: cross-platform UI:

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

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

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

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

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

TonyHenrique commented 5 years ago

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

MarkIngramUK commented 5 years ago

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

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

jesbis commented 5 years ago

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

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

Our initial goal is to:

galvesribeiro commented 5 years ago

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

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

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

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

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

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

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

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

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

Kade-N commented 5 years ago

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

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

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

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

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

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

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

galvesribeiro commented 5 years ago

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

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

galvesribeiro commented 5 years ago

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

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

ekral commented 5 years ago

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

GeorgeS2019 commented 5 years ago

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

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

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

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

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

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

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

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

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

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

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

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

kmgallahan commented 5 years ago

@weitzhandler

This issue was created to discuss the WinUI 3.0 Roadmap.

@jesbis made a clarifying statement:

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

Your first two comments were on-topic.

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

This should remain a productive, professional conversation with Microsoft.

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

niels9001 commented 5 years ago

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

Cross platform & web

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

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

WinUI

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

HoloLens and beyond

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

meteorsnows commented 5 years ago

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

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

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

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

stevenbrix commented 5 years ago

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

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

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

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

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

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

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

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

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

Felix-Dev commented 5 years ago

@mdtauk

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

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

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

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

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

Shidell commented 5 years ago

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

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

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

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

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

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

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

OS Compatibility and Downlevel Support

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

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

jesbis commented 5 years ago

@shidell:

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

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

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

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

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

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

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

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

Shidell commented 5 years ago

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

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

mdtauk commented 5 years ago

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

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

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

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

Mike-E-angelo commented 5 years ago

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

... on Windows. 😉

Mike-E-angelo commented 5 years ago

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

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

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

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

mdtauk commented 5 years ago

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

... on Windows. 😉

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

jesbis commented 5 years ago

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

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

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

Mike-E-angelo commented 5 years ago

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

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

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

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

GeorgeS2019 commented 5 years ago

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

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

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

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

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

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

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

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

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

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

kmgallahan commented 5 years ago

Regarding the WinUI 3.0 transition period

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

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

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

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

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

Regarding WinUI 4.0/3.x/vNext

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

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

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

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

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

edgarsanchez commented 5 years ago

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

TonyHenrique commented 5 years ago

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

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

wbokkers commented 5 years ago

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

mdtauk commented 5 years ago

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

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

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

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

khoshroomahdi commented 5 years ago

What about f# template?

jozefizso commented 5 years ago

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

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

jesbis commented 5 years ago

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

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

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

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

What about f# template?

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

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

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

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

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

mdtauk commented 5 years ago

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

Done #768

jozefizso commented 5 years ago

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

mdtauk commented 5 years ago

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

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

jozefizso commented 5 years ago

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

mdtauk commented 5 years ago

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

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

This is how I understand it.