-
Notifications
You must be signed in to change notification settings - Fork 697
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
π©βπ»π June WinUI Community Call (June 17, 2020) #2649
Comments
Great Job with WinUI 3 preview 1!! Also, there was an issue #1954 reported on leaky |
@harvinders AFAIK Preview 2 is currently planned to be released by the end of this month. |
I have a couple of questions, 1/ What are the plans for MVVM support in WinUI? 2/ Many existing MVVM frameworks (both active and no longer active) implement messaging but they are mostly one-way and require additional messaging callbacks to return responses. Are there any plans to implement request/response pattern so messaging can return objects at the same point of request? For example MediatR does this really well. |
Hey @cirrusone - awesome question! π I can't comment on the WinUI-specific plans (though considering the framework will just support standard BCL types, I don't really see how MVVM libraries should necessarily have anything "WinUI-specific" in them at all), but there's a work in progress brand new MVVM package in the works for the Windows Community Toolkit that should hopefully be of interest of you (full disclosure, you'll see I'm the author, so I might be a little biased here, though I believe the proposal has merit and is solid). Related links:
The package just targets .NET Standard 2.0, so assuming WinUI 3 preview has no issues dealing with the various projections for BCL types/interfaces, it should work right out of the box there too. We're thinking about creating a preview package on MyGet for people to try this out too in the near future. As for your second question, I've added support for "request messages" in the messenger type too. // Define a request message
public class LoggedInUserRequestMessage : RequestMessage<User> { }
// Register the receiver in a module
Messenger.Default.Register<LoggedInUserRequestMessage>(this, m =>
{
m.Reply(CurrentUser); // Assume "CurrentUser" is some local var/field/property
});
// Request the value from another module
User user = Messenger.Default.Send<LoggedInUserRequestMessage>(); Hope this is similar to what you had in mind! π |
What can we expect from WinUI 3 Preview 2? Will there just be reliability and stability improvements and bug fixes or will there also be new features? |
@chingucoding Presumably little to no new features:
|
@Sergio0694 - This looks excellent and good to see significant performance improvements as well. Support for request messages is very exciting as many frameworks omit this very useful functionality. Thank you. |
Looking forward to the call as usual! π I have a couple questions:
Keep up the great work everyone! π |
I guess what would be interesting, besides Win2D eventually being updated for WinUI, to have its documentation updated, and migrated to C++/WinRT instead of C++/CX. Given that those of us in .NET that occasionally need to reach for C++, are now eager for C++/WinRT tooling and examples besides the Photo Gallery sample. Then it would be interesting to know when WinUI will ever provide the WPF features that won't be present in WinUI 3.0, like:
And for the use cases where we have to go down into C++, a VS RAD tooling experience for C++/WinRT similar to what is available to C#, VB.NET and C++/CX currently, without having to manually copy generated files around or write the same information in multiple files in a Notepad like experience. |
Realized I have another question specifically regarding plans for WinUI 3 + .NET 5. Are there plans to properly support AOT tools (be it Ready To Run, crossgen2, etc.) with WinUI 3 on .NET 5 out of the box? By that I mean, just as some built-in option that can easily toggled on by developers, like with .NET Native. .NET 5 is definitely fast on its own, but you really just can't compete with a full AOT binary in cold startup time. Besides, WinUI admittedly has a (small) performance hit over pure UWP XAML due to the architecture changes, so I was wondering whether this plus the lack of an AOT toolchain might cause a noticeable step back in startup time for new apps π€ For some context: I'm currently working on UWP XAML (so with .NET Native), and despite the various shortcomings this compiler/runtime has had in the past (and sometimes still has), I just can't get over how incredibly fast the startup time is for UWP apps compiled in Release with .NET Native. Thanks! π |
Timeline for UWP app model for WinUI and .NET 5/6? |
I remember reading that unsealing framework classes/controls ("unseal all the things") was planned for WinUI 3.0. How is the status on that? Will this still happen for the WinUI 3.0 release or is it now slated for subsequent WinUI releases (such as WinUI 3.x)? |
Hi WinUI team, I had a couple questions regarding Preview 2 Improvements and Fixes:
Thanks! |
I have 4 areas with technical questions / requests for updates - involving specifics of our transition from UWP to WinUI3 Desktop. We will be posting issues soon! First set of questions are related to the FilePicker:
|
Another issue we have come across is that the DataGrid does not display.
|
Are there any updates to TextBox since Preview 1? We have inconsistent behavior with TextBoxes inside of ContentDialog. Most importantly, we are unable to type in text aside for a couple specific characters. Issue with more details to be written soon! |
Are there any known issues with Drag and Drop? Thanks again! |
The MVVM framework compatibility issue associated with ObservableCollection doesn't seem to be addressed by the new Toolkit MVVM API. Are you going to provide backward compatibility with existing code? |
@terrycox There's nothing to address on the library side, that package is just using types/interfaces from the BCL. It's just WinUI that will eventually be updated to properly support them (with projects and whatnot where needed), just like is the case with UWP XAML today and other frameworks too (eg. WPF, Uno, Xamarin, etc.). IIRC @ryandemopoulos had already clarified in the UWP Community Discord server that they do plan to have WinUI 3 fully support all the existing APIs from the BCL, so I guess it's just a matter of time. Of course, this is just my personal comment as an external dev π |
Will there be any news around the ability to get the window handle from a WinUI 3 Desktop window and also around the IInitializeWithWindow interface with CsWinrt ? |
I can't test WinUI with existing UWP code that uses MvvmLightStd10 because of this issue, which was (once) documented for the Alpha at https://docs.microsoft.com/en-us/uwp/toolkits/winui3/#alpha-limitations-and-known-issues. If you try to pull that link up today you'll see only references to Preview1 dating back to May, although the original page was up as far back as Ignite 2019. |
News for Windows Ink support? |
@eleanorleffler, It's expected that you can use the File and Folder picker WinRT APIs. You can find some C++ and C# samples at https://github.com/microsoft/WinUI-3-Demos. We are still working on several things like simplifying how you can get the Window Handle in C#. About the ContentDialog. There is an awful bug that we will fix soon about avoid to input in TextBoxes inside of ContentDialog. |
Hi @marb2000, Thank you for your response! In regards to the FilePicker, we are having issues with DemoBuildCs in particular. I have created an issue with more details! Issue 3 - https://github.com/microsoft/WinUI-3-Demos/issues/3 |
Just throwing this in from the YouTube chat
|
@terrycox the problem isn't with the MVVM frameworks specifically it's with the fact that WinUI 3 UWP is still on the .NET Native chain which doesn't have the proper mapping support. That's why it'll work fine in WinUI 3 Desktop with .NET 5 because of the new C#/WinRT project as @stevenbrix called out on the call. So, hopefully the .NET 5 + WinUI 3 UWP story can be sorted out, and then that all gets automatically resolved. Otherwise, they'll have to go and update the .NET Native toolchain to support this new scenario somehow. So, I believe the effort is being spent looking forward to get .NET 5 + UWP currently and ignoring the current incompatibility with the existing toolchain. |
Also to add to what @hawkerm said, the Toolkit MVVM package does work fine on UWP with .NET Native when using WUX/MUX 2.4, the issue is only when using WinUI 3 preview on UWP π |
Hi, can somebody point me to the source of a UWP app that's properly configured to this Toolkit MVVM package? It looks awesome but I have problems with getting started without any documentation. |
Hey @XamlBrewer - thank you for your interest! π |
This call has ended - huge thanks to our presenters, question-answerers, and everyone who tuned in!
You can watch the recording of the community call here: https://youtu.be/iJoSMC3sHqM
Details
Date: June 17, 2020
Time: 16:00-17:00 UTC (9:00-10:00am Pacific)
Anyone and everyone is welcome - no pre-registration is required.
This will be an informal interactive live stream directly with members of our engineering team.
Format
In this community call we'll be welcoming a community guest and going over some future plans for WinUI.
At the end of every community call we have a Q&A session where our team answers your questions about all things WinUI. Ask your questions in the comments of this issue!
Agenda
Intro, Status Update on WinUI
Community Spotlight: Arlo to speak about the UWP Community Discord Launch 2020 effort
Ecosystem Spotlight: Telerik - Developer Advocate Sam to speak all about Telerik and demo some of their exciting features
Q&A
The text was updated successfully, but these errors were encountered: