Update: WinUI 3 roadmap feedback #888
Comments
|
Thank you for listening to the community feedback. I’m really excited for WinUI 3.0 (Win32 + WinUI + C++). This feels like the framework we’ve been waiting for! RIP GDI 😉 |
So this would basically be the UWP UI, but without the phone-like lifecycle and sandbox? That seems interesting for desktop apps, then – I'll be experimenting with this. |
|
Thank you for the update, and hopefully more updates will come as WinUI 3.0's initial feature set is locked down, and any new controls or control features that have been proposed, which may make it into WinUI 3.0. Oh and documentation about how WinUI in Desktop will work, and differ from UWP, WPF, and Win32 would be very useful to pre-empt the umpteen amount of questions that will come. Perhaps a nice matrix of what is included with which combination of frameworks and APIs, along with the architecture diagrams we got at Build! |
|
You guys are incredible, thanks for everything! |
Assuming this implantation of the UI framework is designed with the idea in mind of portability, at least enough so its UI core (rendering / input) can function under any Windows OS that supports .NET Core 3+ what limitations on Windows 7 would there even be? Seems like most of the features people use on the desktop would just work and for special / platform specific ones that don't, maybe keep them away from being part of the core UI system and keep them in platform specific packages such as (Win10, Win8.1, Win7 Nugets etc). Also if there was a cross-platform XAML that had the same look and feel across all devices (Win32, Android, iOS and WASM) like you can do with HTML (but not Xamarin sadly) my company would have jumped on it years ago. Also glad you guys consider this a "marathon (great Bungie game too)". The less fragmentation in the XAML space the better for everyone and taking to many short cuts will just end you back where you started ;) |
We're working on it and will share more as this develops!
@zezba9000 WinUI doesn't use .NET, and you don't necessarily have to use .NET Core with WinUI: it's a native framework built on OS APIs, and it relies on new functionality in Win8/Win10 that wasn't present in Win7 - in some cases for core features, not just higher-level add-on features like specific controls. |
For Windows 7 compatibility - it would require some third party to build their own compatible renderer for the XAML, as well as some kind of alternative Shim for any OS level APIs needed. Right now there is no idea if this is possible - the hope is that when the WinUI bits are removed from the OS, they are put into the open source project in a way, which will enable other platforms to provide some kind of compatibility component. Think Xamarin, Uno, or .Net Core with a custom renderer. |
In my mind what constitutes a "core feature" wouldn't be something that relies on OS specifics besides of course rendering and input. Which in those cases would be abstraction layers anyone can extend. At a foundational level one in theory should be able to render the UI with a custom software-renderer and do Input with a custom XInput backend with a virtual cursor if so desired. If you can do that kind of modularity you can pretty much do anything and extending the platform support becomes extremely easy (as is done in games). You spend a little more time in this area and down the road everything takes a lot less effort. If WPF XAML was designed this way it could have just been taken and used in UWP apps. Technical debt will just become an endless loop otherwise. Things like tray-icon support etc could be in a "WinUI Windows basic features (Win7-Win10)" package. Things like push notifications could be in a "WinUI Windows extended features (Win8-Win10)" package. Hope that makes sense. |
|
@mdtauk, @zezba9000 it's all theoretically possible, and we have lots of platform abstraction expertise on the team. As with anything, it just comes down to cost, schedule and expected benefit 😊 In addition to development and testing costs (which would extend into potentially non-obvious areas, for example ensuring everything works with old assistive technologies) we also have to consider support cost over long timespans. Do you expect to have new customers on Win7 in 2020+? Feedback and definite use cases do help us prioritize. |
@jesbis I don't see much benefit in adding compatibility to Win7 for WinUI 3.0 - Linux, Android, iOS, iPadOS and MacOS however, may be beneficial for providing a cross platform solution, which does not rely on native UI frameworks. |
No my company does not. I was giving more of a design argument in an area I've seen XAML struggle with in all its iterations (from my perspective) but ya I totally see why MS wouldn't want to spend time there. However it would be cool if WinUI was capable enough for others to do this work if they needed to (which tends to happen I've noticed) without going down a rabbit hole of Windows dependencies as is the case with WPF now. To be clear on what my company would love to see is Android and WASM support be a little more official than UNO (and 3 years ago). We make management software that governs the state of a collection of local computers and system setups usually involving a big need for Win32 APIs (UWP would never work for us but we like the UI because of compile-time errors unlike HTML build systems) and our clients + us need Win32 + Android + Browser UI experiences that have a uniform experience and feel. HTML is just a big pain point as it adds needless abstraction and complexity that otherwise not need be there as our primary code base is in C#. Hope thats better feedback for ya. |
|
Also yes WASM is the biggest target we would like vs any other platform. BY FAR!! |
|
Thank you for listening to the feedback! Desktop + WASM will be gold! |
|
Wow, thank you for the shout out, @jesbis! Totally unexpected and very much appreciated and respected. 👍 |
|
The discussion around Windows 7 is a little distracting, as the amount of effort (not to mention cost) would cause a significant delay to WinUI 3.0. Windows 7 is end-of-life in January, and we’re encouraging all customers to upgrade to Windows 10. My customers may not align with others here, but even Windows 8.1 isn’t a platform of interest for us. |
|
Quite happy with the update. The upcoming targets for WinUI looks very bright and promising! Even the Xplat section was something I didn't expect but is very welcomed. Will look forward to use the improvements as well as the goodies in store for WinUI. |
|
Thank you for the team for transparency. I would like to mention the importance of line-of-business software in helping people in solutions of various problems. I worked for a while with the Lightswitch tool and had a significant gain in construction time. Rapid application development has been very promising for LOB applications. But with the patent wars in the USA is very taken seriously, it took the product to be terminated. We know we have INotifyDataErrorInfo for next delivery. But It would be wonderful if WinUI had RAD resource for future deliveries like 3.x onwards. |
|
thanks team, can't wait for the day when you pencil in webassembly. it will make my day , year and decade and will put MS at the top of the technology stack. WinUI + Xamarin + WASM + .NET => pure awesomeness !! |
|
@jesbis Thanks for this update. Good work team 👍. Understanding it's still early, when do you think we will see WinUI 3.0 milestone created and issues tagged against it? |
@shaggygi Good question! I just created it: |
|
This is awesome guys! Quick question: Moving Windows.UI.Composition into Microsoft.UI.Composition, is this closer to 2.2 or 3.0? |
UIElement isn't in WinUI 2 so it isn't currently in the repo. It will be in WinUI 3 which isn't released or open sourced yet, but we're working on it! You can see examples in the repo of other native controls exposed to .NET via WinRT projections, e.g. the WinUI 2.2 controls documented here. They mostly don't require preexisting per-language wrapper files which is why you're not finding .cs files in the repo. @marb2000 could best comment on the islands/desktop questions. |
|
Q: Will WinUI 3 UWP and Desktop use the same .NET runtime? Q: Will WPF and UWP share the same airspace? Q: Will a WPF app with Xaml Islands compile to ARM64? |
Can UWP use Windows.UI.Composition to create a layer which can get the render from a DirectX bitmap? And then the WPF render the windows to this layer like win2d. Maybe it can share the same airspace. But it hard to make WPF to render to a layer. |
|
@lindexi I guess that could be heaven :D |
UWP Xaml has a number of ways to render DirectX bitmaps or swap chains in Xaml and composite them with Windows.UI.Composition so they share the same airspace, including https://docs.microsoft.com/windows/uwp/gaming/directx-and-xaml-interop You can also insert a Windows.UI.Composition visual into a UWP Xaml UI tree and draw DirectX content to it, e.g. using https://docs.microsoft.com/windows/uwp/composition/composition-native-interop Those approaches should work similarly with WinUI. |
|
A UWP desktop app will be able to reference a WPF/WinForm DLL and open a WPF/WinFrom window? This would allow me to migrate gradually. |
|
@marb2000 -- .NET Core for Windows ARM64 is on our roadmap. I'm working on a plan for that now. |
|
With WinUI 3.0, will it be possible to compile win2d on top of it? |
|
We're still working out details on DirectX integration but hopefully it will be possible to update Win2D to use WinUI base classes instead of UWP Xaml base classes. |
|
fingers crossed :D |
|
sorry if this is off topic: bug reports on UWP - do I add an issue on https://github.com/microsoft/microsoft-ui-xaml/ or elsewhere? |
@jtorjo great question! This repo is the best spot to file any issues related to:
In general there should be a "Send feedback about this product" link at the bottom of most documentation pages on docs.microsoft.com that will tell you the best way to provide feedback on a specific feature or API. For most aspects of UWP aside from the above, that will be to file bugs under the Developer Platform category in the Feedback Hub which has a number of relevant subcategories. |
|
Will WinUI 3 include the UWP SemanticZoom control? I think it's the coolest control of them all. |
|
@jesbis Thanks! Just posted a discussion about System.IO |
|
Even Microsoft doesn't drop Windows 7 support for Office, why would WinUI 3 do? I mean, almost all serious softwares have Windows 7 support (Photoshop, Office, Visual Studio 2019, VSCode, ...) If WinUI does not support Windows 7... |
Office will probably drop support soon, as Microsoft's support for Windows 7 ends very very soon. But it is built upon a code base that already supported Windows 7. WinUI was built upon Windows 10, and so would need to be back ported to Windows 7. The effort to do that makes no sense with the OS entering End Of Life, and so people will have to upgrade to Windows 10. |
So are we getting rid of the UWP sandbox? Which in turn implies UWP in it's current form is also going away, and with it the protected sandbox of the App Store as we know it? |
getting rid of the UWP sandbox would be insanely awesome! |
|
That definitely doesn't mean that UWP is going away. The Universal Windows Platform is the only way to natively build for the full spectrum of Windows devices (PC, Xbox, HoloLens, etc.) and is where Windows is focusing its native platform investments. RE: sandboxing in particular: appcontainer isolation continues to provide a lot of important benefits for apps and users of both UWP and desktop apps. The main changes are:
That means for new apps you'll be able to choose between UWP and desktop app models depending on what makes sense for your app, and if you have existing desktop apps (e.g. WPF, WinForms, MFC) then you can incrementally update them with modern WinUI functionality using Xaml Islands. |
UWP will be one of the options for building a WinUI 3.0 app. Using the UWP will allow your app to run on Xbox, Hololens, etc. But you can also build a Win32 app with WinUI 3.0 and access UWP APIs - but where your app can run will be more limited. |
|
@mdtauk @jesbis I'm totally for UWP, but at this time:
(It took me over a month to port my code from WPF to UWP, since I insanely need win2d, so there's no way for me to avoid UWP.) |
It would be useful for this to be posted in this thread #1517 and hopefully you can include in a name of someone from the SDK team |
Are you using C++/WinRT? If so, are you using pre-compiled headers? |
|
@mdtauk just posted there @MarkIngramUK It's c# code |
|
Closing - please direct roadmap and alpha feedback to: #1531 |
Is this something really on the roadmap or was just an assumption?
Just maybe abstracting it in a way which would make it possible for a third party to make it work on Android or iOS would be huge. I am sure the community can do this. I'd definitely contribute to it. |
|
@andreinitescu Sorry for the rant and complaints but just my thoughts from what I understand: While I'll use WinUI 3 to replace WPF for Windows / Win32 only stuff... Because WinUI on Windows uses a Windows only rendering API and not an agnostic one, WinUI seems to be relying off 3rd parties to re-implement / fragment (ugg) WinUI on other platforms (like the UNO proj, which is cool but it like Mono to .NET is a unnecessary and time wasting fragmentation if things were only designed right to begin with). Instead of using a portable one like Skia, or creating a MS one. Also don't understand the need to support the 1% of people who wont be using C# with WinUI, making C# a second class target in a sense and more importantly making dev time take a lot longer. Just like Android uses Java + post-AOT for many core apps, so should Windows use C# + pre-AOT. Because it saves time. 70% of bugs using C++ are using deallocated ptrs after all. The lack of communication between groups in a company for the long term use cases when its going to become more and more of an issue when they release their Android OS flavor for mobile platforms (which I plan on using) and more people want to target it with MS tools... feel its just going to be another WinPhone7 like situation again in a way. Windows as a term shouldn't be so tied to the WinNT kernel anymore. An eco system is more than a single platform or one companies frameworks its built on. To bad MS can't/wont do what Apple did almost 20 years ago with the move from OS9 to OSX. In that you rip the band-aid off by moving to a UNIX/LINUX kernel BUT having an emulator/simulator built into the OS for legacy software for the next 5-10 years while people migrate software and dev tools over to run natively. (Think what you will of this but I can dream) |
and others
Update: WinUI 3 roadmap
Thanks everyone for the great discussion and feedback so far on the WinUI 3 roadmap (#717)! The team is paying attention to every comment and issue that comes in.
I wanted to give a quick update on some of the main areas of interest that came up.
Availability Roadmap
2.2 Stable Release
The next release of WinUI will be 2.2 stable in July. Further development will continue on the 2.x versions while we work on 3.0 in parallel.
3.0-Prerelease Preview
We're hoping to release an early preview of WinUI 3.0 before the end of the year. We're currently on track but timing will be tight - we have lots of work to do between now and then.
The preview would be missing features but would enable building basic apps to get a feel for WinUI 3.
This should include a preview of Xaml Islands support on Creators Update and up (15063+) for adding WinUI UI to existing apps including WPF, WinForms, MFC. It would also include a temporary Visual Studio template (probably via a .vsix extension) for creating a new UWP WinUI 3 app.
It would not include "WinUI in Desktop" yet (more on this below).
3.0 Stable Release
On track for next year.
Open Source
We're working toward open source but don't have a firm ETA yet. It will start as a branch in this repo.
We're planning to open-source as early as we can and move our active development to GitHub. That means the code won't be fully clean and modern yet compared to the existing WinUI 2 code in this repo - we have lots of Windows C++ code with lots of history 😊
Feedback summary and updates
Some highlights of the feedback we've heard and where we're at, in no particular order:
WinUI in desktop applications
We know that using WinUI in desktop apps is the most interesting scenario for lots of Windows app developers. The goal is to enable using Xaml markup + WinRT APIs (via .NET or C++) as the UI for a win32/desktop app (instead of a UWP app), without needing to use Xaml Islands.
@LucasHaines and @marb2000 are working closely with the .NET and Visual Studio teams on this and can share more details as the work evolves.
Note that UWP support will be ready before win32, just because UWP is less work.
Our focus is still Windows 10 and 8.1, but we hear the feedback that some of you still have users & customers on Win7 and we'll be evaluating the market and options over time.
Tooling and templates
We're still planning to (in order):
(UWP app model) + (WinUI 3.0 UI) + (.NET or C++ language)
(Win32 app model) + (WinUI 3.0 UI) + (.NET or C++ language)
We're also starting to think about what migration helper tools we might build, starting with tools to migrate existing UWP C# apps. Your feedback on this has been helpful!
F# support
It was awesome and informative to hear all the feedback on F# and the potential benefits for Xaml apps. @kathyang - one of the interns on the WinUI team - has been investigating this and talking to the F# team, and would love to hear your ideas in the tracking issue #740.
Just to set expectations: if we did anything to support new languages it would have to be after the initial WinUI 3.0 release, just because we have lots of work to do to get 3.0 working with the currently-supported languages first. It's also possible that we could accept community contributions after open-sourcing WinUI.
Cross-platform UI
We hear you about .NET and cross-platform UI. This is a complex area with lots of potential opportunities.
The WinUI 3.0 release is focused on providing a great solution for Windows client developers, but we're thinking about future opportunities. We're also big fans of the Xamarin team and are in touch with them.
Some of you also mentioned Uno specifically: we think nventive (creators of Uno) had a great presence at Build the last couple years and our team spent a good amount of time talking to them to understand their approach to technologies and industry.
WebAssembly is also increasingly interesting and on our radar. We think this is an exciting space with many improvements on the horizon which Microsoft is continuing to invest in, and we love the work that Mono, Uno, Blazor and others are doing.
INotifyDataErrorInfo etc.
@LucasHaines is working on getting the input validation work we showed at Build 2019 fully integrated into WinUI 3 and would love any further feedback on:
Features (new & old)
New features
We've shifted active feature development on Xaml from UWP to WinUI 3.0. That means most new features will require WinUI 3.0 to be a bit more stable before we can start development on them. We review every proposal that comes in and we've started tagging those proposals in with the needs-winui-3 label so we can revisit them as soon as we can.
Please do keep filing new feature proposals for things that would help you use WinUI 3!
Desktop parity (e.g. WPF)
Thanks for sharing the feedback about WPF parity and ensuring WinUI 3.0 is a fully featured platform for rich desktop development. This will continue to be an ongoing effort for us.
For background info, some of the goals of UWP Xaml included:
Which required some changes to previous Xaml functionality, including:
As well as improved threading, hardware acceleration and many other optimizations.
TLDR:
WinUI 3.0 includes many features that aren't in WPF, but WPF has some features that aren't in WinUI 3.0.
We're continually working on expanding the features in WinUI Xaml and Composition, so if there are specific WPF features you rely on that you'd like to see in WinUI 3 then keep letting us know by opening a new issue, commenting in the "WPF features that should be in WinRT XAML" #719 issue that @mdtauk started, and voting on existing issues/comments.
Your continued feedback will help us prioritize what to focus on!
Thanks everyone!
WinUI 3.0 is a marathon and not a sprint so keep looking for updates over the coming year.
Special thanks to all-star commenters like @mdtauk, @MarkIngramUK, @galvesribeiro, @Mike-EEE, @TonyHenrique, @eklipse2k8, @mrlacey as well as @weitzhandler, @jozefizso, @simonferquel, @reli-msft, @kmgallahan, @GeorgeS2019, @meir-pletinsky, @zezba9000, @mfeingol, @bchavez, @Shidell, @KyleNanakdewa, @Happypig375, @wbokkers, @meteorsnows, @ekral, @contextfree, @Pinox, @GeertvanHorrik, @shaggygi, @riverar, @r7dev, @natemonster, @mfe-, @khoshroomahdi, @jkoritzinsky, @edgarsanchez, @charlesroddie, @4creators, @wjk, @vitorgrs, @thomasclaudiushuber, @paulio, @niels9001, @lhak, @huoyaoyuan, @anthcool, @Suriman, @RyoukoKonpaku, @GiorgioG, @Felix-Dev, @dotMorten and everyone that gave feedback on the roadmap so far!
Please leave a comment if you have other questions.
The text was updated successfully, but these errors were encountered: