-
Notifications
You must be signed in to change notification settings - Fork 683
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
👩💻☎ December WinUI Community Call (Dec 16, 2020) #3791
Comments
Asking again as its almost a tradition now... Progress on Acrylic and Reveal. On a more serious issue - There have been a few visual updates proposed, for individual controls. Is there a high level set of concept designs you could share, showing how you envisage the whole visual style looking for apps? The roadmaps mention updates every 4 months, but is that set in stone, or could some missing features come out earlier as and when they are ready? Oh and one final thing. What is everyone's Christmas Day tradition/routine |
What is the progress on open-sourcing WinUI 3? I see no reason why we cannot use a tiered model of source release (where only pieces of the codebase are released at a time, as they are ready, like what happened with WPF). Waiting until all features are ready before allowing third-party contributions to any of them does the community a great disservice. Many of the unhandled issues on this repo could probably be quickly and easily fixed by the community, except that we still don’t have access to the any of the code. You said WinUI 3 would allow community contributions. Prove it. Furthermore, WinUI 3 preview 3 does not support use in a UWP CoreWindow anymore, meaning I cannot make a .NET 5 app that runs in an AppContainer for security and privacy purposes (since the two are codependent). I must still use the Frankenproj UWP project system, and by extension to the long-since-deprecated .NET Native compiler. I do not appreciate being told I have to program using only 2013-era technologies and forego any of the innovations in the ecosystem since then. Most importantly: By now Microsoft has announced years and years’ worth of technologies and projects, and then time and time again has been too lazy to follow up on any of them. Remember that some of the things listed under the “Coming in WinUI 3.x” column in the roadmap were originally promised to be available by the end of 2018. I, as a community member and a .NET evangelist, am quite fed up with being told “Please wait, coming soon.” Put up or shut up. Follow through on your promises to the community or stop making new ones. (The ideas and issues under the ProjectReunion repo also suffer from this problem, but they don’t do community calls, so I am asking here.) I apologize if I sound unfairly harsh, but this is how I feel. Thank you for your attention. |
The current contenders against WinUI are: Visual Control Library and FireMonkey with C++ Builder. https://www.embarcadero.com/products/cbuilder With graphical designer VB/Delphi style and cross platform support, no need to manually copy files around or mess with IDL files, a couple of extensions similar to C++/CX are required. No big deal, latest versions of C++ Builder make use of clang anyway. Qt/Qtcreator, just released version 6 this week: https://www.qt.io/product/development-tools https://www.qt.io/product/ui-design-tools With graphical designer VB/Delphi style, a Blend like tool with integration to Photoshop, Sketch among others, cross platform support, no need to manually copy files around or mess with IDL files, a couple of macros on the same file cpp are enough, build system takes care of the grunt work of binding everything together. WinUI 3 with C++/WinRT, currently a developer experience reminiscent of using Visual C++ 6.0 with ATL and is Windows 10 only. Going forward, what are the roadmap items that would make WinUI a viable option in regards to tooling, given that those C++ frameworks ping back on top of Windows APIs anyway, while offering a .NET Windows Forms/WPF like developer experience for C++ developers. Because for 2021, with the growing list of Project Reunion issues, and lack of support for C++/WinRT GUI tooling, and being Windows only, it is starting to be really hard to advocate why WinUI and not VCL, FireMonkey, Qt, where such GUI tooling is available with the benefit of being cross platform as an added bonus. |
Agree with @mdtauk - would be super nice to see some "concept art" of how the new control styles would look like in context. |
Are they any plans if or when will be WinUI 3 adopted by Windows Shell and apps like File Explorer or Microsoft Office desktop? Thanks! |
Is it possible now or in future to automate WinUI through COM Interop? For example can Excel/Word/Powerpoint add-ins use WinUI? |
Will WinUI 3 ever support unpackaged (plain .exe) desktop applications? Have you considered the possibility of exposing WinUI to other languages like Python or Java? With the current build and deployment requirements, it doesn't look good. |
It seems that WinUI 3 carries its own copy of Windows Composition. Does it run in-process now? What about system-wide DWM integration? Has the development of built-in composition stopped? |
WinUI 3.0 desktop apps. In UWP you obviously create an appx packages, but there is also an option to create an eappx package ( encrypted appx package - this carries MS enterprise encryption). Is something like an encrypted single file exe package possible with WIN 3.0 desktop apps ? |
Not sure if this is the right place because the situation right now is more than confusing but what is the status of WPF in general and in regards of WinUI. It's really a shame that WPF doesn't get any love while WinForms has been getting fixes and even new features. |
Can you ship prerelease more frequently? |
Are there any options for proper/desktop data grid controls in winui 3 c++/winrt available right now ? |
Will using an ExecutionAlias be supported in the next release? |
I can make a single instance WinUI Desktop work with a mutex and a named pipe, but that's a bit cumbersome. Can we expect guidance here? |
How can I get toast activation to work with WinUI Desktop? Will that work the same way as in current win32 apps? (https://docs.microsoft.com/en-us/windows/uwp/design/shell/tiles-and-notifications/toast-desktop-apps) |
There are many controls and new features suggested in the WindowsCommunityToolkit (WCT) but many have been there for months and years, eg canvas view, text editor, grid, propertygrid, ribbon control etc. Is it possible to i) identify a roadmap by feature/control as to whether it's likely to be developed for WinUI or WCT? |
Hi! Two questions! The DataGrid in C# crashes for WinUI 3 when scrollbars are used. Is there a timeline for when we will see that fix? Will Win2D will be added in a WinUI 3 Preview version, i.e. before the 3.0 Release? Thanks! |
@eleanorleffler Please see here: microsoft/Win2D#707 (comment) |
Great question @cirrusone, sorry I couldn't make the call this morning. Thanks @anawishnoff for fielding an answer. For background I talk about the relationship between the Toolkit and WinUI in this video here. Just like the WinUI team we get many feature requests. There's so many great experiences developers need to build great apps. Both our teams do our best to deliver new controls for developers to build with, but we can't build everything all at once. 🙂 Luckily, as we're open source projects, we have great communities which are helping bring many things forward. For instance, we have a community member working on a Ribbon-type control now. We rely greatly on these community contributions to push the bounds of what we can deliver to developers. It's why the Toolkit exists! To be more specific to your questions:
If you have suggestions on how we can be more transparent about this, please let us know. For the Toolkit we have a new Wiki which can show you how to get started contributing to the Toolkit itself. Thanks! |
I would like to get excited about WinUI. What’s particularly frustrating about where things are headed is the fact that WinUI feels like yet another reboot of XAML tooling with steps being taken backwards rather than forwards. May I please get a frank answer to the following: (1) Why is the .Net Native compiler being abandoned? Is it because it’s hard? There was a lot of fanfare around the original promise of what was coming and rightly so. C# would have C++ like perf using .Net Native and would no longer be susceptible to easy reverse engineering. Having to use an obfuscator is a non-starter at this point. Such tooling always introduced a degree of instability and performance decline because of how such tools worked. The .Net Native promise was a big deal and not delivering on it will push a lot of folks away from C# and back to C++. (2) What is the future use case for UWP? There were many promises associated with UWP adoption, again with much fanfare about the benefits and rightly so. Some of these being: A sandboxed execution framework that protected the user. A simple, safe, accessible and efficient deployment mechanism via the Microsoft app store. An installation framework that was dead simple on both sides of the fence, install and uninstall, without any mess left behind. Tooling that automatically generated app packaging for multiple CPU architectures. It’s actually a very long list … (3) When will the sandboxed WinRT API ever become stable? There have been problems with the file system APIs not honoring FutureAccessList rules (ZipArchive being a glaring example). Camera APIs not correctly initializing Focus/Zoom settings. MIDI APIs being broken for years on end. SVG rendering being minimally conformant. UI APIs breaking old code as changes become non-conformant with previous XAML code. UI rendering bugs that never get fixed (PlainProjection comes to mind). This too is a long list. (4) Why keep dodging 3D XAML support. It was there in WPF. It’s tooling that is becoming more essential with time. Work seems to have stopped on Windows.UI.Composition.Scenes. Again, promises were made that are being broken. (5) When will Validation and the promised support for INotifyDataErrorInfo ever arrive? This was promised in 2018 as being around the corner? If Microsoft has any doubt as to why UWP adoption has been poor, it’s because API quality has been lackluster in some parts of the API surface and promises keep being broken (another huge broken promise was Windows Phone). For the XAML diehards that went from WPF to Silverlight to UWP to Xamarin Forms, the experience has been more than a little bewildering. Rather then evolution, we get constant reboots with our UI code base having to be tossed every few years. On the .Net API side it has been the complete opposite. Ever better perf, stability, reach and tooling. I don’t want to over emphasize the bad here. XAML and it’s binding infrastructure has lots of future ahead. The WinRT API perf benefits have been huge, especially on close to the metal operations like media handling in general and graphics compositing in particular. The .Net Native compiler was a huge leap forward and has reached an impressive level of capability where it stands today. The touch screen APIs and Inking, Mapping APIs, Media handling APIs and a many, many other esoteric parts of the API surface have been fantastic both in quality and capability. The integration of existing libs introduced with .Net Standard 2.0 was also a huge benefit for UWP. Lastly, Microsoft, please stop eating your children and start keeping your promises. |
It seems .net native compiler received no longer investment in favor of CoreRT, which was finally superseded by NativeAOT project, which aims to merge features of CoreRT with existing features from mono native AOT. The project was essentially reboot to benefit from mono AOT experience (used for mobile dev) and CoreRT experiment. Because Blazor wasm will require AOT, the priority for this project is now quite high. And now the project tracks multiple concepts. One of them is trimming and the need to remove as much as reflection code as possible to allow better trimming, using newly released source generators when possible. So .NET 6 is the target for modern native AOT. I think .net native compiler future is this project. |
@tbolon, thanks for the insight. There are conflicting concerns that are often hard to reconcile. It is clear that one set of objectives is overriding another with respect to where UWP in particular is going. My sense is that Microsoft isn't really listening to the right consumers of its tech when it comes to UWP. For serious companies publishing to the Microsoft Store, it's not feasible to be giving away your intellectual property in the form of easily decompiled IL, nor is it reasonable to be using fragile obfuscation tech given how difficult it is to keep up with evolving IL. I certainly won't be doing it. It's also clear Microsoft does not like to use IL for any of its serious projects so I'll follow their example and start swapping out C# if the timeline for NativeAOT appears indefinite. I can see why Unity moved to IL2CPP. They couldn't wait either. |
Here's the 3D UWP XAML starting point that hasn't been touched for months: https://github.com/windows-toolkit/SceneLoader |
Here's the promised INotifyDataErrorInfo for UWP: https://www.youtube.com/watch?v=4chzzzAZRNQ |
The start of the .Net Native hype: https://www.youtube.com/watch?v=JoE7OytQWj0 |
@Noemata Here is my understanding about the current and (forseeable) future landscape of Windows app development and why developers should consider picking the UWP app model.
So... you can target Xbox, HoloLens, Surface Hub, 10X with UWP...ok, while that is all fine and good, what if my app only needs to run on the Desktop? Why not pick Win32 (i.e. WinUI Desktop) then ? This leads me to the second case for the UWP app model, this time from a consumer perspective:
Two things to note here:
So, speaking as a consumer here, I would much rather install a UWP app instead of a Win32 store app because I know that by default UWP apps will respect my privacy and can only access system resources I give them permission to. I'm not sure how relevant the default guarantees of the UWP app model (i.e. the user permission model) for Windows users are. Windows has a long tradition of its users just downloading a program from the web and installing it, where they don't really ask (or are bothered) about what that program might do besides its officially advertised functionality. With the advent of smartphones and their OS app permission models, perhaps a new generation of customers is in the process of arriving on Windows - customers which will greatly value having considerable control over what an app is allowed to do and when. The UWP app model, as outlined above, has clear advantages here over Win32 programs and could become a selling point. Footnodes(a) It has to be stressed that while decoupling many defining components from the UWP app model and making them available to Win32 apps is a major goal of Project Reunion, this is a process where we are very likely talking about years here. It is also unknown to what exact extend current UWP-exclusive features will be made available to Win32 apps. It is not a given that all default features of a UWP app (such as the windowing model) will be made fully available to Win32 apps (which goes the other way too, not all features of Win32 apps have to be made available to UWP apps). |
@Felix-Dev thank you, that was very helpful. |
Currently WinUI is reaching 14000 items, and it was clear from the community call that we should keep believing WinUI will have a place among Forms, WPF, Blazor, Xamarin, Uno, and whatever comes next. Also that in what concerns 3D, the team position is that .NET developers should abandon the confort of .NET tooling and write raw C++ code, with a developer experience far from what C++/CX was capable of. If I need to write C++, then I rather go with Qt, not only is the tooling experience way better than the team is willing to improve C++/WinRT, it works on all Windows platforms as WinUI, Mac, Linux, Android, iOS and lots of embedded POSIX platforms. Noemata check their 3D scene graph support, with DX, Vulkan and Metal backends. |
You write your app for a specific tech stack because of what it has to offer. The Windows App store and trusted app deployment was a big selling feature of UWP among many other details. If I really wanted a C# tech stack with maximum reach, Unity is probably the most pragmatic choice. Unity is starting to cover a lot of ground, especially as we move into more graphically intense application development. UWP seemed like a good call a few years ago. It still would be were it not for Microsoft's bizarre indulgence with eating it's own children (from a tech perspective). The WPF and Winforms children are now being regurgitated at the expense of the consumption of UWP. Xamarin too is in flux. The question Microsoft should ask itself is how is Unity able to maintain such a consistent path forward? The answer is pretty obvious, they commit and deliver on their promises. Microsoft has some of the best minds in the industry, as well as staggering resources, but the company suffers from so much internal strife that you would think their biggest challenge is managing the competition between internal divisions rather than external forces. |
This call has now finished but you can watch the recording at the following link. Feel free to open up issues on this repo for any follow-up questions!
https://youtu.be/RGmm341kJMI
Details
Date: Wednesday December 16, 2020
Time: 17:00-18: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
This month's call will be a Fireside Chat edition! It'll be a super casual, direct conversation between the WinUI team and you! We won't be welcoming any guests or making any big announcements this time around, but rather sharing some smaller updates and leaving most of the call time for Q&A.
Leave your questions below as well as any general topics you'd like to hear about on the call!
The text was updated successfully, but these errors were encountered: