WinUI 3.0 roadmap - we need your input! #717
Comments
jesbis
changed the title
|
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:
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 IslandsAs Xaml Islands becomes easier to make possible - replacing old webview controls, colour pickers, XAML based Dialogs could be as easy as a Add New... and choose a Dialog, or standard control which existing C# and C++ code can call into, and they have their own codebehind. Modern app and page templates like Xbox Next apps, NavigationView, Master/Details, Hubs, Modern Ribbon, NavigationViewTop, and Pivot - could all be made available for all Windows Presentation Platforms - with XAML Islands in place and sample content. Any of these scenarios which are not currently possible in UWP XAML, should be with controls and templates to make these easier. Would it help if Visual Studio or another tool automatically updated namespaces for you?It should be a question asked when someone opens their project on the latest version of Visual Studio with a current Windows 10 SDK. Press the button and it either replaces the name spaces and using, or flags them if it is not a control it is familiar with. On new projects it should be the default, and the nuget package installed along with future versions of the Windows SDK. What would be your preferred solution for using UWP components with WinUI 3?As with the automatic updating answer, New pages and projects should include it by default, and a message asking if they want to Automatically move to WinUI | Add ToDo comments to update namespaces | Do not move to WinUI. What kind of apps would you be most excited to use WinUI 3.0 for?As a user I want all apps running on Windows to share a common UI and UX no matter what framework was used. I want apps to be installed without messing with the registry and leaving junk behind. (so Centennial) I want all the apps to be installable from within the store, or from a Centennial type installer. Virtualise the System and Windows folders for every app. Modernizing a C++ MFC app with Fluent UI?Acrylic should be available to WPF, WinForms, and MFC apps, and included in default new templates via a WinUI 3.0 dependency or manifest. CommonControls and window styles should use Acrylic and extended titlebars (which can be overridden to go back to the current defaults) Microsoft's Win32 non UWP apps need to all be recompiled with WinUI 3.0 so they all use Acrylic window frames, main menus, ThemeShadows, Context Menus, Text Fields, Progress Bars etc. And then existing apps need a simple solution to drop in WinUI 3.0+ which then updates the looks of all the controls - or the ability to apply it selectively one dialog at a time, until the entire UI is updated. |
|
re: namespaces, I would expect them to just change based on the target even it requires conditional namespaces. |
|
Here are my answers: Creating a new app
Adding WinUI 3.0 to existing Win32 apps
Updating your existing UWP Xaml app to WinUI 3.0It 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. |
|
Also, just want to mention that this is a very welcome move, and having the whole UI framework open source on Github is awesome! Thanks a lot for doing this! |
|
First of all, this is a great move! Unfortunately I cannot neglect the fact that I feel a bit hurt by the way Microsoft has dealt with the few last developers on their platform. At the moment I only use UWP for consumer-facing apps because:
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 questionsCreating a new app
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 appsI 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.
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.
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.0Consumer 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.
If it's just namespaces, a search / replace should do the trick as well.
No longer important, I am willing to take the loss of thousands of hours of development, there are no users left anyway.
Nope.
UWP Islands (sort of hosted components) General
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").
Probably just adding new views to a WPF app and slowly start migrating. |
|
I very much like this roadmap. UWP needs to be freed from its shackles, and this is a great way to do just that. Updating your existing UWP Xaml app to WinUI 3.0This 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
Existing styles should still work. I can live with some minor visual changes. But not with changes in behavior.
No.
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
|
|
Please do not introduce new namespaces for stuff like INotifyDataErrorInfo - it should be used in view models that are usually cross-platform and should not have dependency on WinUI. It should be defined where other stuff like this is located (i.e. INotifyPropertyChanged or INotifyCollectionChanged) |
|
I would just like to know if the ultimate goal is to create a cross-plat UI stack. Understanding it might not be completely understood how we get there. However, if that is the intent... it would be better to brand this without the Win references at the beginning of this effort. It will be less headaches in the long term if you did. Would it be better to label as XamlUI or similar? The Microsoft.UI.* namespaces are fine, just brand the repo and such as XamlUI 3.0 or similar. Thanks for reaching out. Look forward to what's to come in this space 😄 |
|
To me, all the technical details are less important. TBH was disappointed me on last Build to discover the MS has no plans on making UWP or XAML cross-platform. Uno got no official recognition other than a speech. Even more frustrating, I'd say hurting, was to discover that MS is giving so much love to React Native and HTML/JS driven frameworks AGAIN (WinJS), while neglecting its loyal .NET stack devs. And BTW, I have been working with XF since its acquisition by MS, and wish it had an alternative, for following reasons: a. No web support, b. Very mobile biased, no love for desktops c. Its library hierarchy feels sloppy, definitely when compared to WPF/UWP control-library d. Is not using MS XAML. Thanks y'all! |
|
We need a XAML UI that also runs on the Web (Assembly). At least a subset of UWP. |
Quick replies for the questionsWhat templates would interest you most?.NET core SDK-style projects, or some simplified MSVC project format. 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. My personal look for the UI platformXaml toolchainThe 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 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 A better windowing modelIt's regular for information-full, state-full application to use multi-window model instead of navigating model. Currently in UWP, creating new window using Rewriting Visual Studio in WinUI at sometime future can prove it to be a mature UI system. Data binding interfacesWe are very tired for creating models implementing And there are threading issues. My data come totally from a background network server, so context capturing for 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".
|
|
@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. Microsoft does not need to be the ones working on those alt platform renderers. But focusing on Windows for now... WinUI 3.0 could encompass Fabric Web / React Native / WPF / WinForms / MFC. PWAs will also be a first class citizen for app development, so there are cross platform stories for apps not made for Windows/.NET/UWP directly. What is needed now, is to provide a story for C#/.NET/UWP devs to bring their apps and investments to the wider landscape of platforms. |
|
My 2 cents: I'm a Xamarin.Forms dev, and (like many others) am interested in seeing all XAML dialects being merged into one that works everywhere, including the mobile space. Not sure how that would go down, but that's at least my wish on the matter. |
|
WinUI 3.0 onwards perhaps - but there are too many WPF apps out there to expect them all to re-write and translate all that XAML. New WPF projects could use the more modern WinRT XAML dialect. You could introduce the equivalent of a DocType to XAML so different dialects could co exist in the same project. Easier said than done of course. |
|
@mdtauk I think that once the Xaml platform is actually made open-source, we will have a clearer understanding about what it relies on on the bottom of the stack (we already know that the main platform-specific dependencies are DirectX11, Direct2D and Windows Media Foundation, but who knows what part of the Windows SDK is used there), and how it is layered (so that we can have an actual feeling about the feasability of any porting). |
|
Android uses Vulkan and I think supports OpenGL As for the media codecs, it may be possible to make use of native C based APIs to substitute. @simonferquel It will become clearer when the code is refactored and checked in. And it may require some iOS and Android experts to lead those efforts. |
|
I think changing the namespace was a reasonable approach when winui was collection of controls. However, now that it basically replaces the platform, I think this is not justified anymore. This is already works in same way for WPF/Winforms, where code can be moved from .net Framework to .net core without changing the namespaces in code. The platform should automatically be able to load the winui versions of the necessary dlls when enabled. In this way, source and binary compatibility (I have successfully used .net framework libraries in .net core apps) can be preserved. |
|
Just wanted to say thanks everyone for the comments so far! The WinUI team is looking carefully at all the responses and points. |
|
@jevansaks Thanks for the info on the Datagrid control. This does not deal with the issues of printing reports and pagination, exporting and such. These are real life business scenarios that need to be dealt with, not whether some button animates (as nice and as cool as this can be). @hupo376787 From what I can see Dev Express are the only ones who currently provide a full stack for creating and viewing reports for UWP, and their pricing seems to be on the premium side. All the others including Telerik have gaps in their tooling which means reports for UWP cannot be created. I'm willing (hoping) to be corrected on this. |
@hupo376787 please take extra care to check your facts before implying a posting is incorrect. Telerik Reporting has a report designer for WPF and WinForms but not UWP. DevExpress also has a report designer for WinForms and WPF, but not UWP So please check your facts before committing yourself to an error that will be preserved in perpetuity and circulated widely. Hey that sounds like it might be an old proverb one day 😉 |
OK, I think we have the different understanding of Reporting. I mean https://www.telerik.com/universal-windows-platform-ui and https://www.devexpress.com/products/net/controls/win10apps/. |
|
I was incorrect, Dev Express do not provide reporting for UWP. It appears no third party tooling developer does! I contacted Dev express through their chat, about whether they had a road map for providing reporting for UWP. @jevansaks, it seems there is a lack of communication between the Microsoft UI team and these third party tool providers. We would be happy to use third party tooling, but it looks like the UWP platform makes it difficult for these companies to integrate the tooling they have for other platforms into UWP. They asked me to contact their [email protected] with our reporting requirements, it may be helpful for the Win UI 3.0 team to get in contact with them and see if their is a way to assist them in implementation. I don't see how you will get business devs on the universal platform without proper reporting tools. |
|
Reporting: just from a WinForms perspective, I've used both Telerik and DevExpress (even their latest versions), and while Telerik was good, I think DevExpress not only has a better overall designer and experience, but has a lot more subtle features that allowed me to do more complex layouts than Telerik. I think the DevExpress rendering technology is more advanced. |
Thanks for the call-out. We'll reach out to them as well. |
It may be worth talking with all of them and seeing what the blocks are? Telerik, Grapecity, DevExpress etc. |
For sure, that's our plan. |
|
We're a bit different than most developers building for Windows. We develop mostly kiosk apps (apps intended to be run by users other than the computer's owner, and typically full-screen without any access to the broader system). The apps are generally built to the specific requirements of the customer, with no intention to distribute them through the store or equivalent. Because the apps run full-screen, there's very limited value in the built-in controls maintaining the look and feel of other Windows apps; instead they tend to be highly branded for each customer. We do still need a lot of common behaviour and controls from standard Windows apps, but we typically do a lot of customisation of each one's control templates or at least override their core styles. For a very long time we built a lot of apps as WinForms backends with embedded Flash frontends for UI. Broadly speaking almost every app we write integrates some kind of web-based backend with some piece of hardware (e.g. a printer, a barcode scanner, a mag stripe reader, an RFID scanner, a camera, card payment hardware, vending-style cash payment components, etc.), and the vast majority of those components historically have come with Win32 SDKs and not UWP ones. For those two reasons, most of our historical apps are WinForms apps, and most of our modern apps are WPF ones. We have built a few UWP apps (largely to benefit from the really nice Assigned Access/Kiosk mode capabilities of Windows), but they're typically a pain to work on compared to WPF, and we typically can't get compatible hardware SDKs anyway. We are very much intrigued by XAML Islands though, to allow us to write Win32-compatible apps with modern UI (although the advantage of UWP over WPF to us is not always clear, especially if we're not using standard controls or Microsoft-specific effects like Fluent, etc.). To answer your specific questions:
C# with .NET Core, Win32 with WinUI 3.0 overlaid would be nice.
Yes, and I was relatively happy with them when I've played with them, although we're not likely to use a single control, so much as making a decision for the whole custom UI. The main reason I was aware of it was because we'd get Lottie support for Win32 apps.
Not really; we almost always control the target PCs and can ensure we're always getting the latest compatible release.
Yes.
Very minimal. The main compatibility headache we'd have would be changed StaticResource keys for styling core elements.
Yes, we have used the Syncfusion UWP control library in the past.
The preferred solution would be to have more standard controls available in WinUI itself rather than leaning on outside sources (e.g. document viewers), but I expect those external component libraries would typically be more progressive about updating their libraries than we'd be at switching to WinUI 3 anyway for the most part.
I'm excited to see UWP controls being more clearly decoupled from the UWP app and security model that has historically locked us out due to hardware compatibility reasons, especially since WinUI is being designed and developed in the open. With such clear guidance about how Microsoft recommends us to build app UIs, I would expect all our apps would end up with WinUI frontends, regardless of which backend we can support.
Mostly about getting access to more actively-maintained libraries of controls in my older apps, with nicer, more obvious documentation (or even access to the underlying code for the standard control) makes it much easier to figure out when I can adapt a standard control and when I need to roll my own user control. For example, in a recent app built in WPF I had a couple of date pickers; getting that control to work nicely for touch, and customising the size, font, pop-up icon, etc. was extremely annoying. I'd be inclined to use WinUI for that sort of app by default in the future given the roadmap above, because:
|
|
I see that this has been closed, but there are a couple of issues that get raised by our users which I though would be worth raising. They are productivity improvements for users who work with large amounts of data. TextBox: Gridview/ ListView: These are two issues raised by our users as very annoying.
|
|
I'd recommend that you create a new issue for each of the improvements you mentioned. The WinUI team will then triage to determine if they'll require WinUI 3 to be released before implementing or not. This issue existed primarily to garner feedback regarding the 2 "General Questions" at the top of the post. |
|
Support the Blazor hosting model native in WinUI. This would allow a Blazor control to be used directly in Client/Server web, or used directly in WinUI. The Blazor roadmap has this future concept without using a WebView control. This way the control's UI runs native with the .Net Standard portion of the code also running native. |
Discussed on the Blazor side, FWIW: |
@jevansaks Would be great to get into the loop as well. |
|
I'd like better consistency of Tray Menus / Icon Menus with WinUI 3.0. Every App has a different spacing, and Win32 apps do not follow the font rendering / spacing / themes consistently. Please fix this already! |
|
WinUi in desktop completely useless for me due to lack of any windows management possibility: show/hide windows, windows position, windows size, dock/undock ... |
|
@alexandrevk it is still a preview. Did you see the windowing API design? microsoft/WindowsAppSDK#157 |
|
Thank you @dotMorten for linking to the windowing announcement post! @alexandrevk - we are putting together APIs for Reunion that will allow you to do these type of windowing operations from both Win32 and UWP with WinUI content as well as when using other frameworks/swapchain content in your window. Some of these windowing features may then be abstracted into the WinUI window class for easier access as well, but that is further down the road. Feature specs for the windowing area are in the pipe, stay tuned. |
|
Speaking strictly as an invidual user (ie: non-corporate/company) and c++ only, even if i am just a lone voice shouting into the void, i feel the need to say, that as long as any of these new UI systems are tied to UWP and that horrible packaging system they build into, then i'm afraid it will always be in the dark whatever you do. (Speaking from WinRT experience, havn't tried WinUI yet but it looks pretty much the same to me). |
|
@nl-n you should be happy to know that one of the big deals with WinUI is that it doesn't require to run as a UWP app. In fact this has been possible since preview 2. |
|
@dotMorten That's one of the big issues: requiring side-loading/installing via the store. i don't know a single person who doesnt disable/strip the store before (or just after) installing windows, so how are we supposed to distribute them?. To quote @MarkIngramUK near the beginning of this thread:
which (funnily enough) i am literally having to do right now, and yes it is just as painful as it sounds :) |
|
@nl-n who said anything about the store? MSIX isn't really different from installing from MSI. It's just an app installer. Double click it to install. No store needed. Guarantees a 100% clean uninstall too (as opposed to MSI which makes a giant mess) |
It's not common though.
First of all, you need to inform users to not disable the store)
MSIX can be installed without a store. With latest Windows versions user don't need to enable anything for that. Of course if package was signed before with trusted certificate. But yeah, if user removed store from the PC, then he could also remove MSIX/APPX AppInstaller from it as well. In that case they probably don't want all variability of applications.
It's their choice. Nuff said.
Single SDK is about 3GB. It isn't required to download every one starting 10240 one. |
That was from the description visual studio gives you, 'for sideloading/installing via the microsoft store', the only other information i've found on msix is from the msdn, which basically says: msix packages are sandboxed/virtualized 'appx' applications, which is pretty much a killer for anything working directly with the winapi. And they require signing to even be installable?... It could also just be crossed wires i suppose, too much differing teminology, and i don't know much about UWP.
More common than you think, and with reason 😄 Anyway, it wasn't my intention to derail, so i'll go back to writing my CreateWindowExW stuff for now 🤣 |
microsoft-github-policy-service
bot
added
the
needs-triage
and others
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).
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).
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:
Windows.UI.XamlMicrosoft.UI.XamlWindows.UI.CompositionMicrosoft.UI.CompositionWindows.UI.InputMicrosoft.UI.InputWe're exploring options for helping you automatically update namespaces when retargeting your UWP app to WinUI 3, at least for .NET apps.
2. Mixing UWP and WinUI Xaml components
The fastest path to releasing WinUI 3.0 would be to not support mixing:
with:
Microsoft.UI.Xaml.UIElementandMicrosoft.UI.Composition.Visualelementsin 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.
General questions
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?
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?
The text was updated successfully, but these errors were encountered: