Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

First WinUI 3.0 Alpha now available πŸš€πŸ‘©β€πŸ’»πŸŽ‰ #1531

Closed
jesbis opened this issue Nov 4, 2019 · 41 comments
Closed
Assignees
Labels
discussion General discussion product-winui3 WinUI 3 issues

Comments

@jesbis
Copy link
Member

jesbis commented Nov 4, 2019

WinUI 3.0 Alpha now available!

As mentioned in the community call last week we now have a super-early WinUI 3.0 Alpha build available!

We'd love it if you could try it out and let us know what you think about the direction and roadmap.

Please note that it's a very early prerelease and has lots of known issues and missing functionality so it isn't ready for shipping apps. Future previews and the first stable version of WinUI 3 in 2020 will add support for everything outlined in the roadmap.

Installation info

For installation info and known issues see:

WinUI 3.0 Alpha (November 2019)

There's a super-short survey with the download link - we'd love to know more about how you're interested in using WinUI.

Please try out the Alpha, let us know what you think and open issues if you run into any bugs that aren't listed already!

What's new?

The major updates so far are:

  1. WinUI 3 no longer depends on Windows.UI.Xaml: the full Xaml framework and parts of the composition and input stack have been decoupled from the OS and ship via NuGet

  2. WinUI 3 works downlevel! The Alpha works with min version 1803 (April 2018 Update)+ and we're working on expanding the supported version range. For example, new features like Lottie Animations exported from Adobe Illustrator and Input Validation via INotifyDataErrorInfo now work on a range of in-market OS versions:

image

Uno

In other exciting news we're also working with the Uno platform so that developers can bring their WinUI code anywhere WebAssembly runs – including Windows 7. For more info you can check out their recent blog post: https://platform.uno/WinUI-on-Windows7-via-UnoPlatform/

What's next?

As outlined in the roadmap we're hard at work getting WinUI ready for open source development, plus working toward a more complete preview, .NET Core support, and more!

@jesbis jesbis added discussion General discussion winui3Ξ± labels Nov 4, 2019
@jesbis jesbis pinned this issue Nov 4, 2019
@jesbis jesbis self-assigned this Nov 4, 2019
@kmgallahan
Copy link
Contributor

kmgallahan commented Nov 4, 2019

Future updates will add support for additional project types and languages, including .NET Core 3.1+ and the desktop (win32) app model.

So is the alpha still running on .NET Native or .NET Core 3.0? If the former (assuming so due to dependencies), will 3.0 not be a target in the future?

@jesbis
Copy link
Member Author

jesbis commented Nov 4, 2019

The alpha works with .NET Native or C++ for now, and RTM will support .NET Core. Really it probably shouldn't say 3.1 at this point since we're still working out versioning with the .NET team but hopefully it'll be open source before then so it should be easy for everyone to stay up to date on what's going on πŸ™‚

@vitordelucca
Copy link

When will the code be open?

@jesbis
Copy link
Member Author

jesbis commented Nov 4, 2019

@vitorgrs we don't have a firm date yet but we're working on it now - it's currently our main focus.

@vitordelucca
Copy link

@vitorgrs we don't have a firm date yet but we're working on it now - it's currently our main focus.

Thanks!

@mdmozibur
Copy link
Contributor

Don't forget the Compact Sizing in WinUI 3. It was announced at probably build '18 but supports just 2-3 controls till now.

@jesbis
Copy link
Member Author

jesbis commented Nov 4, 2019

@Muziburrahman have you tried using the Compact style dictionary in WinUI 2 (and 3)?

https://docs.microsoft.com/windows/uwp/design/style/spacing#fluent-compact-sizing

It should automatically adjust various Text and List controls, ContentControl, TreeView, DatePicker, TimePicker, ComboBox, NavigationView, etc.

Are there specific other controls you think should be adjusted?

@mdmozibur
Copy link
Contributor

@jesbis Of course, what about RadioButton, CheckBox ?

@jesbis
Copy link
Member Author

jesbis commented Nov 4, 2019

@Muziburrahman those should also have compact margins already by default when using the compact style:

image

@jesbis jesbis added this to the WinUI 3.0 milestone Nov 4, 2019
@weitzhandler
Copy link
Contributor

Wow!! The Uno bit enlightened my day!
That is freaking awesome! Congrats Microsoft and Uno 🍻

@agoodwin
Copy link

agoodwin commented Nov 6, 2019

First I'd just like to say thanks to everyone involved in WinUI. WPF has been the most "cutting-edge" Windows UI framework that I've had the chance to work with in my career, generally because of the restrictions of UWP combined the usual legacy code problems that make modernising difficult, so I am really looking forward to using WinUI 3.0.

Everything I've read since first coming across the roadmap sounds great. The separation of XAML from the underlying app model is perfect, for example. Being able to soon use features like x:Bind for compile-time binding checks in WPF applications (or rather, applications using the Win32 app model I guess I should say) is something I've wanted for years and has been the main thing missing from XAML for me. I only recently discovered it was actually something that already existed in XAML, and has been enjoyed by UWP developers for a while.

On top of that, finally getting access to all of the nice controls that conform to Fluent Design, and having them available in WPF with XAML Islands, plus all of the other stuff – it's basically everything I've always wanted for Windows desktop development arriving at the same time. It looks like it's going to be so much easier to create Windows applications with a great look and feel right out of the box now. So thank you again.

I just have a couple of questions around timelines:

I think my first question would simply be, is it fair to say that it's unrealistic to expect any kind of production-ready version of WinUI 3.0 by February 2020 (even as a fairly stable pre-release)?

Basically, we have a project for an internal tool going on right now with the intended release date being in February 2020. I would love to be able to create it as a "pure" WinUI 3.0 app, because I think that will both reduce the development time of the UI significantly and result in a UI that wows the users well beyond anything they are expecting.

The next level of complexity though, is that in reality this new tool is most likely going to have to be created as an addition to an existing tool of ours, and that existing tool is built using WPF on .NET Framework 4.7.2.

With all that in mind, is my understanding correct that probably the best bet for us (in order to have a modern-looking, Fluent-based UI for the new tool at all) is going to be to:

  • Keep our existing application as a WPF application
  • Port it from .NET Framework 4.7.2 to .NET Core 3.1 (I believe this is needed to support the final point below)
  • Create UWP class libraries using WinUI 2.3 for the new tool's views (i.e. custom controls)
  • Use XAML Islands to host these modern views in our WPF application

The correctness of that approach would be my second "question". Knowing the existing tool as I do, I have my doubts that we're going to be able to get it onto .NET Core 3.1 anyway, and then of course there's the issue of the new and old UIs clashing too much, but I'm trying to keep my dream alive here...

Anyway, if a rough indication for those two questions is possible it'd be much appreciated.

@dpaulino
Copy link
Contributor

dpaulino commented Nov 6, 2019

Let me know if this is the wrong place to ask, but is there a migration path from current uwp apps to WinUI + dotnet core 3? Will the migration require code changes?

@mdtauk
Copy link
Contributor

mdtauk commented Nov 6, 2019

Will the Uno implementation be in a browser, or will it be possible to run the app in its own window?

@dpierangeli
Copy link

dpierangeli commented Nov 6, 2019

Will the Uno implementation be in a browser, or will it be possible to run the app in its own window?

"Run your app on Chromium through Electron"

It seems that Electron will encapsulate the WebAssembly and run it.

@danzil
Copy link

danzil commented Nov 6, 2019

@dpaulino We're looking at all options for migration to WinUI. Currently, we're seeing a migration path where all you'd need to do is target the WinUI nuget and search and replace "Windows.UI.Xaml" to "Microsoft.UI.Xaml" + small code changes for certain types that don't benefit from .Net's custom projections such as constructors for Color, Thickness or INotifyPropertyChanged, etc. Our goal is to make switching as easy as possible, so if the list of things you need to gets too involved, we'll definitely explore fixing that or adding tooling to make it painless.

@jevansaks jevansaks added the team-Controls Issue for the Controls team label Nov 7, 2019
@msft-github-bot msft-github-bot added the needs-triage Issue needs to be triaged by the area owners label Nov 7, 2019
@jevansaks jevansaks removed the needs-triage Issue needs to be triaged by the area owners label Nov 7, 2019
@jesbis
Copy link
Member Author

jesbis commented Nov 7, 2019

@agoodwin thanks for the comments! We greatly appreciate the feedback - it's especially helpful to hear about what kinds of apps people are building and what features are important. We definitely aim to make it easier to develop modern native apps with WinUI 3.

If your release timeframe is only 2-3 months away then extending your existing app does sound like the most reasonable approach. If you're able to migrate to .NET Core (or alternatively write the new views in C++) and all of your users will be running the Windows 10 May 2019 Update or later then using Xaml Islands to host new views created with UWP Xaml + WinUI 2 can definitely be a good incremental step toward a future WinUI 3 solution if that ends up making sense for your app.

@carmineos
Copy link

I can't wait for WinUI in win32/desktop with .NET Core!

@mdtauk
Copy link
Contributor

mdtauk commented Nov 7, 2019

WinUI 3.0's stable release will be the start. What happens after will make or break the platform in the longer term.

Will it speedily address the needs of developers from all camps?

Will inbox apps currently "stuck" in Win32 legacy UIs, be moved to WinUI?

Will "limited" UWP apps find better performance and new powerful capabilities, when released from the sandbox?

Will the dev story be clear and compelling to the big companies like Twitter, Facebook, Apple, Google - and bring apps to Windows in its various form factors.

And the biggest unknown will be how Microsoft converges its Windows and Android inbox and big apps to work seamlessly on Windows 10, 10X, Xbox Scarlet and Surface Duo's Microsoft flavour of Android?

@lindexi
Copy link

lindexi commented Nov 9, 2019

I do not think support win7 by Electron is good way. Why we need to run in our platform but dependent on Electron.

@maxkatz6
Copy link
Contributor

maxkatz6 commented Nov 9, 2019

@lindexi
It's better than nothing, when Win7 shouldn't be supported at all.
Also full backporting to Win7 is time consuming, so it's better to spend Microsoft resources to make WinUI better on Win10. IMHO.

@Berrysoft
Copy link

I try to port a small program to WinUI 3 Alpha, and it surprises me that it lacks the DPI awareness... It's not by design, right?πŸ˜‚

@lindexi
Copy link

lindexi commented Nov 11, 2019

@Tirraon I total agree with your point. But this behavior will zip the WPF space in Win7. "Look at here, the UNO use Electron, the Electron is better than WPF ... "

@Berrysoft
Copy link

But this behavior will zip the WPF space in Win7. "Look at here, the UNO use Electron, the Electron is better than WPF ... "

You're right, but every new-born framework may zip the old ones. UWP will zip WPF on Windows 10, and WinUI with Xaml island will zip it too.

@lindexi
Copy link

lindexi commented Nov 11, 2019

But this behavior will zip the WPF space in Win7. "Look at here, the UNO use Electron, the Electron is better than WPF ... "

You're right, but every new-born framework may zip the old ones. UWP will zip WPF on Windows 10, and WinUI with Xaml island will zip it too.

I dont think the Electron is in dotnet technology stack. I am willing the UWP zip WPF but I dont like the Electron zip WPF.

@jevansaks jevansaks removed the needs-triage Issue needs to be triaged by the area owners label Nov 11, 2019
@MouriNaruto
Copy link

Looks good. But I wonder to know when WPF XAML will replace the WinUI XAML because we want a universal modern user experience.

@mdtauk
Copy link
Contributor

mdtauk commented Nov 21, 2019

Looks good. But I wonder to know when WPF XAML will replace the WinUI XAML because we want a universal modern user experience.

Xaml Standard fizzled and died. WPF XAML is I think a 2009 spec, whereas WinUI XAML is 2006.

I hope .Net Core 5 and WinUI 5 could perhaps complete a transition to a unified and open spec 2021 XAML spec.

@zezba9000
Copy link

Any thoughts when a WinUI 3.0 alpha for Win32/Desktop will be available?
For work this is the only target that has enough features for our management software. Can't wait to dable in it there.

@jesbis
Copy link
Member Author

jesbis commented Dec 5, 2019

We don't have a firm date for the win32 preview yet but we'll let everyone know when we do!

@lhak
Copy link

lhak commented Dec 7, 2019

I did not see AppWindow on the list of the currently not supported features, but it seems that the required APIs are currently missing.

@jesbis
Copy link
Member Author

jesbis commented Dec 7, 2019

@lhak sorry, thanks for pointing that out (and for trying the alpha!) - it's not currently supported. I just opened a PR to get it documented in the known Alpha limitations.

@weitzhandler
Copy link
Contributor

weitzhandler commented Dec 11, 2019

@jesbis (here)
The alpha works with .NET Native or C++ for now, and RTM will support .NET Core.

The problem is that C# 8 only works against .NET Core 3. Pretty big limitation in the alpha version.
Anyway, I'm looking closely and appreciate all your countless efforts πŸ’–

@milos12345
Copy link

Will WinUI 3.0 work with WPF? If yes, will it work without XamlIslands? If no, will there be a choice to use it with C# and without UWP, and on something that does not run in sandbox?

@hanneslarsson
Copy link

hanneslarsson commented Feb 12, 2020

Would love for the PermissionRequested event to be in there in an early stage as this is an important one for accessing camera and microphone in order to use WebRTC. Or is there a new way to handle the webcam and microphone permission request from the webview?

@bughandler
Copy link

any news about WinUI3.0 with win32 app model?
I can't wait for it.

@Felix-Dev
Copy link
Contributor

@amyhaber A WinUI Desktop preview with Win32 support is slated to be released around Build next week.

@bughandler
Copy link

@amyhaber A WinUI Desktop preview with Win32 support is slated to be released around Build next week.

awesome!

@Pinox
Copy link

Pinox commented May 14, 2020

@Felix-Dev when you say win32 are we now talking about a .net core build ?

@mdtauk
Copy link
Contributor

mdtauk commented May 14, 2020

@Felix-Dev when you say win32 are we now talking about a .net core build ?

AFAIK WinUI Desktop will support C++ and C# with .net core

@Felix-Dev
Copy link
Contributor

Felix-Dev commented May 14, 2020

@Pinox As @mdtauk said. Taken from the WinUI 3 roadmap:

image

AFAIK support to create a new WinUI Desktop app targeting the .NET Framework is not going to be added to WinUI Desktop.

Here is also a comment by @ryandemopoulos about the WinUI .NET story given in a recent community call.

@krschau krschau added the product-winui3 WinUI 3 issues label Jul 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion General discussion product-winui3 WinUI 3 issues
Projects
None yet
Development

No branches or pull requests