👩‍💻☎ December WinUI Community Call (Dec 16, 2020)

anawishnoff commented 3 years ago

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!

mdtauk commented 3 years ago

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

wjk commented 3 years ago

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.

pjmlp commented 3 years ago

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.

niels9001 commented 3 years ago

Agree with @mdtauk - would be super nice to see some "concept art" of how the new control styles would look like in context.

aerojam commented 3 years ago

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!

cirrusone commented 3 years ago

Is it possible now or in future to automate WinUI through COM Interop? For example can Excel/Word/Powerpoint add-ins use WinUI?

nnemkin commented 3 years ago

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.

nnemkin commented 3 years ago

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?

Pinox commented 3 years ago

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 ?

StefanKoell commented 3 years ago

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.

huoyaoyuan commented 3 years ago

Can you ship prerelease more frequently? The quality of WinUI 3 Preview 3 is still far from GA. We need more previews to confirm that important bugs/workarounds are fixed.

niclar commented 3 years ago

Are there any options for proper/desktop data grid controls in winui 3 c++/winrt available right now ?

wbokkers commented 3 years ago

Will using an ExecutionAlias be supported in the next release? See this issue: https://github.com/microsoft/microsoft-ui-xaml/issues/3441 What issues can we expect to be fixed in the next release?

wbokkers commented 3 years ago

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?

wbokkers commented 3 years ago

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)

cirrusone commented 3 years ago

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? ii) identify at least an general plan, eg feature/control parity with Winforms/WPF or smaller set of controls etc ii) if there are no plans for development of feature/control can we have guidance to build are own in WinUI

eleanorleffler commented 3 years ago

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!

wjk commented 3 years ago

@eleanorleffler Please see here: https://github.com/microsoft/Win2D/issues/707#issuecomment-740361674

michael-hawker commented 3 years ago

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? ii) identify at least an general plan, eg feature/control parity with Winforms/WPF or smaller set of controls etc iii) if there are no plans for development of feature/control can we have guidance to build are own in WinUI

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: 1) All our planning is done in the open for the Toolkit here: https://github.com/windows-toolkit/WindowsCommunityToolkit/projects, we even have a tracking issue for our upcoming release here. 2) There's a general WPF gap tracking thread here for WinUI. We've already added many WPF-gap controls to the Toolkit like DockPanel, UniformGrid, and more. 3) We work closely with the WinUI team as well, for instance a community member wanted to improve ColorPicker, so we're working on trying out improvements in the Toolkit first before they can get back to it after WinUI 3.

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!

Noemata commented 3 years ago

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.

tbolon commented 3 years ago

(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++.

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.

Noemata commented 3 years ago

@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.

Noemata commented 3 years ago

Here's the 3D UWP XAML starting point that hasn't been touched for months: https://github.com/windows-toolkit/SceneLoader

Noemata commented 3 years ago

Here's the promised INotifyDataErrorInfo for UWP: https://www.youtube.com/watch?v=4chzzzAZRNQ

Noemata commented 3 years ago

The start of the .Net Native hype: https://www.youtube.com/watch?v=JoE7OytQWj0 (A big wow, even today)

Felix-Dev commented 3 years ago

What is the future use case for UWP?

@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.

1) One core feature of the UWP app model is the ability to target all Windows 10 device categories. Only with UWP, can developers write apps for Xbox, Surface Hub (running Windows 10 Team), Windows 10 IoT Core and HoloLens. It will also be the only platform where developers can expect best native performance on future Windows 10 device categories/OS variants, such as the upcoming Windows 10X. So while local Win32 support with performance on par with UWP apps could be possible for future Windows 10 variants (i.e. the Win32 development story might have changed for 10X since the Developer Day presentation in February this year), only with UWP can developers be confident in that support.

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:

2) Only with UWP can consumers feel confident that a random UWP app they download will feature the following:

A clean uninstall experience
Respecting user privacy/keeping the user firmly in control
only consuming system resources when needed (i.e. suspended by the OS when app is minimzed by the user)

Two things to note here:

Yes, UWP apps can launch Win32 processes which can then access (user) resources which UWP apps normally don't have access to. However, this requires the declaration of a restrictive app capability which is subject to Microsoft's approval (if distributed via the store). As such, only apps which truly need such a capability will be allowed to be uploaded to the store. And if customers sideload an UWP app, they will see a list of system resources the app has access to on the MSIX installation dialog.
It is true that with Project Reunion, the different components of the UWP app model are in the process of/planned to be made available to Win32 apps as well (a). This is already the case with the MSIX app package format and in the future there's a good chance the AppContainer component (which regulates resource access permission such as access to the file-system) will also be officially supported for Win32 apps (b). However, one significant difference here is that all these features are just optional for Win32 apps. There is no guarantee that a random Win32 app will support these features, let alone all of them. Yes, Win32 store apps use the MSIX package, but what about the AppContainer? What about a battery-friendly app lifecycle?

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). (b) Right now, win32 developers can already have their apps run in an AppContainer but that concept is not yet production-ready, especially for .NET desktop apps.

Noemata commented 3 years ago

@Felix-Dev thank you, that was very helpful.

pjmlp commented 3 years ago

@Felix-Dev @Noemata

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.

Noemata commented 3 years ago

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.

microsoft / microsoft-ui-xaml