👩💻📞 WinUI Community Call (January 22, 2020) #1857
Comments
msft-github-bot
added
the
needs-triage
StephenLPeters
removed
the
needs-triage
|
Can we talk about support for nullable data types in controls and default values? As an example there is
Also, what is the roadmap for fixing the open issues on the NumberBox that do not depend on WinUI 3.0? It would be great to start using this control around WinUI 2.4 instead of having to wait longer. It's not fully baked yet in my opinion and I'm uncomfortable pulling this into production apps. |
|
Another interesting idea to discuss I've wondered about: What will Microsoft's policy be on breaking changes now that WinUI 3.0 is going open source? In the past, Microsoft has virtually never made breaking changes. This is generally a good thing until all the clutter builds up after a few (or 10) years. It's also not the standard for open source projects. For example, eventually ListBox should be phased out for ListView and MessageDialog phased out for ContentDialog, etc. I'm sure there are lots of nicer little clean-ups in the API as well. I know businesses hate changes -- for good reason. There also MUST be a relatively easy (functionally equivalent) drop-in replacement available to make porting to new APIs straightforward. This would need to be evaluated on a case-by-case basis and a judgement call made. I'm wondering if we could establish major releases (WinUI 4.0 for example) as allowing breaking changes. This will allow the project to continue to grow without having to live with all past mistakes. Essentially, Microsoft has already decided to do this with .NET 5 by basing it on .NET Core and dropping what was the full .NET Framework. This might be good to document once it's discussed. |
|
Based on progress made since the last call, when does the team realistically think WinUI 3 will be ready for release:
Also, how dependent is your work on the .NET team putting together a new AOT solution and .NET 5? Lastly, is there pressure on the Windows side to have it ready for Windows10X release and/or prior to that for developers to make specialized apps? |
|
Will there/should there be a tool to easily convert WinUI 2.X projects to WinUI 3.0 (since doing this manually might be a lot of work for large projects)? |
|
The Elephant in the room - WinRT (#1856) |
A non-sandboxed app model is coming - which will run in the same way as WPF (including Win32 APIs), but with access to modern WinRT APIs, and open sourced UI and controls with the new XAML running on Direct X 12. |
Wow. Wow Wow!!!! That is beyond amazing! Do we have an ETA for this, will it be discussed in the call? It's insanely awesome! |
It was the first thing we learned about WinUI. ETA is for this year, I suspect a definite date will be given at //Build/ - but feel free to ask during the call. https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md |
|
@jtorjo See the WinUI roadmap. Also see #1045 for more info (such as VS project templates). |
|
@mdtauk @Felix-Dev I'll re-read those docs. I do remember asking this before - as long as I can easily use win2d from my (non-sandboxed) app, I'll be more than happy! |
|
@jesbis Sorry for the noob question - how do i join the call? |
|
We're setting up the info for tomorrow's call later today - I'll post the directions in a few hours. The delay is because it's our first time using a new broadcast system - after this it should hopefully go smoother and be ready earlier 🙂 |
|
I just had an interesting thought (to me anyways). Glancing at today's ASP.NET Community Standup livestream I saw essentially 4 MS devs doing a livecoding stream, although it was more of a tech demo. I also occasionally tune into @csharpfritz on Twitch who does full on live coding sessions. So my thought was - after WinUI 3 is released and the codebase (or most of it) is all open source, would any team members be up for occasionally livestreaming some of their work on WinUI? It would be a good opportunity to grow WinUI exposure, help people casually explore the codebase, and questions could be fielded once in a while. ~I wouldn't recommend full on chat engagement all the time as that would be super counterproductive, but maybe a Q&A once in a while. I have no idea what MS policies are on that type of thing, especially during the workday. Would be interesting to hear your thoughts. |
|
Here's the YouTube live event link for tomorrow! Thanks for all the comments and questions so far! We'll try to get to everything, or keep track for a followup if we don't have time. |
|
Is there anything in the guide about performance / fps of the ui? One of the biggest gripes I have with modern Windows 10 is that on a machine like Surface Book you get some awful performance on high DPI displays, made even worse when you combine transparency and additional monitors. It might be out of the reach of what's possible, but is there any considerations here about how fluid and well it performs, especially under these conditions? |
|
Learning more about the 'future of windowing' for WinUI would be nice - there are a lot of related requests that would be nice to atleast discuss/address. |
|
Probably have been asked before. To me, is always been a matter of code reusability.
Another one, when will we be seeing the missing bits from WPF supported in UWP? |
.NET Core code should work on both, so a WPF app would only need to change UI Xaml and UI code. UWP apps should work fine with a namespace change for WinUI 3.0 - breaking out of the sandbox may need more work, the details are still unknown. WPF missing bits have not been confirmed, but I made an issue about it. #719 |
|
Although it isn't officially supported and not all of the C# 8 features will work, you can already use most of C# 8 with WinUI/UWP. See here. I do this and haven't run into any issues. "Default interface members and Indices and ranges" appear to be the only missing bits, although I haven't tried everything. |
|
Just amplifying what kmgallahan said about using C# 8. I've been using many of the new features, but really wanted Default Interface Members, which aren't implemented yet. |
|
Thanks folks. |
|
Does WinUI require C++/CX? If so seems like this is an issue for Win32 and other future targets? |
The WinUI Xaml framework's rendering is primarily implemented on the Windows 10 composition engine. The composition layer APIs will also be part of WinUI 3. In the end that generally means hardware-accelerated rendering using Direct3D, Direct2D and DirectWrite, with software rendering in some cases where it makes sense. You can also include your own custom-rendered DirectX content using interop APIs.
No - the WinUI platform is written in C++ but your apps definitely don't have to be! With WinUI 2 today you can create UWP apps using .NET (C#, VB.NET) or C++. With WinUI 3 our goal is that you will be able to create apps that use UWP and/or win32 APIs using the upcoming .NET 5, or C++. |
|
@jesbis I think you may be misunderstanding my questions intent a little.
2.a) Is the "Visual layer" an abstraction API removed far enough away from DirectX APIs that it could later support a Vulkan backend for example? (I'm sure this question will be answered when the source is released but I'm just wondering) 2.b) My question about software rasterization was more along the lines of: Will WinUI 3.0 support full software rendering (not just text rendering or what-not)? Sometimes screen sharing software has issues with GPU accelerated apps (at least with D3D9 / WPF) and forcing software rendering on fixes the issue in those situations). Or if the app is ran in a VM with no hardware GPU. |
did that with Edge New the download link doenst showed up, repeated it with chrome- download there |
@hannespreishuber the download link should be on the last page of the survey. Do you mean that the survey didn't work in Chromium Edge but did work in Chrome? |
did survey on both - but last page was diffrent, perhaps my fault. |
Okay, thanks - we tested the survey on both versions of Edge and it seemed to work so if anyone has problems with the download please let us know, and also report the problem in Edge if page content renders differently than Chrome (Settings > Help & Feedback > Send Feedback) 🙂 |
@zezba9000 we've implemented WinUI 2 controls and features (the new code currently in the repo) using C++/WinRT which is standard C++17, but the rest of WinUI 3 is a much larger and older codebase that will currently still rely on WRL etc. We aren't focusing on portability at this time but are open to discussing it in the future.
We're not focusing on portability at this time for the visual layer either. There are some loose couplings between the Visual layer and DirectX APIs (not counting implementation) but it's mostly abstracted. Also, to clarify about open source: our initial target for open sourcing code and our day to day development processes is the Xaml framework, which will not include open sourcing the visual layer at this time.
Yes, rendering over screen sharing, in VMs etc. should all work. For most content there should be no visible difference. If you look through the WinUI 2 code in the repo you might also see usage of an API we use to query whether certain effects are supported/"fast" at runtime and fall back to simpler rendering of certain effects in some cases, but apps shouldn't have to do anything special to support software rendering when using default platform controls and features. |
Agree 100% - I don't even wanna recall the number of hours I'm spending working around bugs from UWP/WinRT. |
|
Jesse, I'm primarily concerned about developing enterprise applications. I am currently using WinUI 3.0 Alpha to build a proof of concept to demonstrate how Xaml, GPRC, multiple windows and true multi-threading can offer the business and the business user a more productive application experience. Why? Because we need an alternative to browser-based/small screen applications. I have lots more to say on that topic, but I'm going to KISS here. What I would like from the WinUI team and indeed Microsoft is to embrace and support building desktop apps for business. There were 3 main reasons web apps were adopted in the enterprise so quickly - cross-platform support, security and easy of deployment To be a viable alternative, desktop apps need answers to those questions. It seems most of the software development industry is focused on delivering applications for the browser and/or mobile/tablet form factor. Enterprise applications run on workstations with lots of CPU, screen size, memory, storage, graphics and bandwidth when compared with “mobile first” applications. The users of these LOB applications may engage for hours and hours at a time. We need app design guidance to address these factors. There are other dimensions in enterprise applications that do not get much discussion – longevity and skillset. Again, lots to say here, but I’m going to summarize. Businesses invest money in building applications and they plan to use those apps for a “long” time. This means the underlying technology needs to be supported for decades. I would like to see WinUI be that next long-lived technology to replace Win32/MFC and WinForms. IT departments constantly struggle with finding SEs with the right skillset. Web tech has made this even more challenging. I would like to see a new stack C#, Xaml and SQL (C#XS) that identifies a focus on building desktop apps. There is also a minor point I would like to make with respect to styling. WinUI enterprise applications should require a minimum of styling “out of the box” in order to be functional. Also, and this might be directed straight at Fluent, but don’t hide controls (like scroll bars). Business users have plenty of screen real-state and do not care how “gorgeous” a UI is if they do not know there is more on a page. We need a robust (free) datagrid control. Can’t emphasize that enough. I have more ideas to share if you’re interested, but I’ll stop here and summarize: • Microsoft needs to provide a comprehensive desktop application development solution. Hope you found this helpful. |
|
@robloo Rest easy - no debate needed! 🙂 I committed to fixing this lapse in my early comment and that still holds true. I think I also made a mistake earlier by continuing to generalize. Let's talk about the bugs you listed. Two were filed right before our major holidays here (I can't speak for @teaP, but I was offline most of December) and we went through a management change on our engineering side (congrats @ranjeshj!). It's no excuse and I apologize that these two bugs were not attended to more swiftly during these changes and absences. The others listed here have all been filed within the last 10 days or less. To have it pointed out that NumberBox in particular is a culprit and that these are stacking up helps us be strategic with our time, so thank you for helping us see this. I have scheduled time early next week to review our outstanding NumberBox bug list with our NumberBox dev @teaP and our (newly titled) engineering manager @ranjesh so that we can get to resolving them collectively ASAP. |
|
@SavoySchuler Thanks! |
|
@SavoySchuler , it seems you're stuck in a difficult position of choosing between: a) Fix bugs in WinUI 2.x, and delay the release of WinUI 3.0 I guess that a lot of existing WinUI 2.x users will want you to fix the bugs first, as they are currently affected, but perhaps this could be mitigated by offering a realistic expectation of when WinUI 3.0 could be available, given sufficient resources (and assuming WinUI 3.0 will offer additional fixes over 2.x). Personally, I would not want to see a delay in the release of WinUI 3.0, and think it's reasonable that the community get involved in solving any issues that are critical in WinUI 2.x (after all, it is open source). Some people have the expectation that because it's Microsoft's project, they should do all the work. Unfortunately that's not realistic, and nor is it how other open source projects work. @jesbis , it's interesting hearing about the Visual Layer with regards to WinUI 3.0. Are you saying that for the initial releases, WinUI 3.0 will have a dependency on For reference, things I'm interesting in:
|
|
@infoequipt thanks for the in-depth notes! Definitely helpful. @marb2000 for visibility |
@MarkIngramUK no, sorry for any confusion - my earlier point was just about open sourcing. Microsoft.UI.Composition will be part of WinUI 3 and Microsoft.UI.Xaml will depend on it. That's already the case with the WinUI 3 Alpha. We're working toward open sourcing Xaml, which means the Xaml framework code will live in this repo and our engineering team will be doing all our day to day work on Xaml on GitHub going forward. However the Microsoft.UI.Composition package that Xaml depends on will still be internally developed and only updated in binary form. |
|
Thanks for the clarification @jesbis much appreciated. What distribution methods will you be using for this? We’re a cross-platform app, so using CMake, and have a dependency on Windows.UI.Composition, so would love a way of easily bringing in the new dll, lib, headers etc. Are there any performance implications for extracting the Visual Layer from the OS? I.e. if you only depend on the Visual Layer, would there be a downside to updating to new library? Is there a plan to eventually open source Microsoft.UI.Composition? |
|
@MarkIngramUK I largely agree with what you are saying, and what @SavoySchuler is saying in a 'big-picture' view. As you pointed out though, it's harder for us WinUI 2.0 users to accept bugs as we have production apps right now. We need to find a compromise between fixing some bugs that won't delay WinUI 3.0 and also keeping WinUI 3.0 on track. There was an additional frustration that NumberBox was a brand new control that appeared to immediately be neglected -- with a comment that Microsoft wouldn't circle back to it for over a year. Regardless, I certainly agree WinUI 3.0 is the priority and wouldn't want it to be delayed in any significant capacity. I probably should say I do appreciate all the work Microsoft is doing here and their efforts to be more transparent and communicative with direction. |
@MarkIngramUK would consuming NuGet packages work for you? I.e. what we're doing with WinUI 2.x and the WinUI 3 Alpha. We're still working out some distribution details with the Visual Studio team. Right now the WinUI 3 Alpha contains both Xaml and Composition binaries in 1 package but we'll be separating them to support open sourcing Xaml and being able to build Xaml separately.
Stay tuned 🙂 Perf benchmarking and work is on our roadmap for later this year so it's a bit too early to have any numbers.
It's on our backlog to potentially consider but we don't have a plan for it. @MarkIngramUK if I could ask: what benefit would you hope to get from it being open source? Composition and rendering code can get a bit abstruse so I'm curious whether people would actually be interested in contributing or using as a reference. |
@robloo thanks! We're really trying to be transparent and it's good to know that's valuable 🙂 Just to reiterate what Savoy mentioned we do have devs working on WinUI 2.x (as can hopefully be seen from the PR log too) so we're definitely still investing in both WinUI 2 and 3 in parallel - it's just that most of our resources are on WinUI 3. I agree about NumberBox in particular needing some attention and our Xaml controls dev lead is looking into it now. |
|
@robloo You're the best! 😄 Sorry again for the confusion - the only thing that subject to that ~1 year delay mentioned was NumberBox's additional input validation modes because they are blocked on our all-up input validation work slated for 3.0. Otherwise @teaP, @ranjeshj, and I will be on the NumberBox bug list starting next week. 🙂 I think @jesbis got everything else covered! |
|
@jesbis ,
I'll be honest, I'm not that familiar with NuGet, but looking at this SO answer it seems it will only work if you use CMake to generate VS project files, which is not how we normally work (normally just open the folder, which uses Ninja as the generator). It's a shame you can't ship the source, as you could use vcpkg as well. For reference, we build all libraries from source (which avoids any potential ABI problems, especially given that we build with Clang/LLVM on Windows too).
I have an interest in this, so I'd love to get involved in the discussion if / when that happens.
Initial thoughts are contributing / expanding (as I mentioned previously, we have a dependency on Windows.UI.Composition, but not the Xaml Framework / UWP), though thinking out loud, porting the Visual Layer to a Vulkan or Metal backend for cross-platform might be exciting, but I've only given that literally 30 seconds of consideration. Also, open sourcing would alleviate a nagging worry of adopting another framework that will eventually be abandoned by Microsoft in a few years time (our current apps are built on WPF, our previous apps were built on MFC, we had web components using Silverlight, so, you may see where I'm coming from here...). |
NumberBoxHi everyone! @teaP, @ranjeshj, and I worked through all our open NumberBox items today.
Thank you to everyone for working with us. 🙂 We ❤️ WinUI! |
|
Is there a "calendar" for the WinUI Community calls? Ex: in the form of a public calendar that we can add/integrate to our live/google/* calendar, for automatic updates of call details. |
|
The YouTube events are scheduled ahead of time so you can add a Google reminder here under " upcoming live streams": https://www.youtube.com/channel/UCzLbHrU7U3cUDNQWWAqjceA We also had a .ics calendar invite but it was causing problems for some people and there was no way to update it so we gave up on that for now. |
and others
Update
Thanks everyone who could make it live! We'll try to get to the rest of the questions here.
Call recording is here:
https://youtu.be/MXTVqgB4rW0
Hi all -
The next WinUI Community Call will be on Wednesday Jan 22!
Details
Date: Wednesday January 22
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 online call directly with members of our engineering team.
Please leave questions/topics/feedback!
We'd like to spend part of the time answering your questions again, so please leave comments in this issue if there are any questions or topics you'd like us to cover next week!
If you've tried out the WinUI 3 Alpha then we'd also love to talk about any feedback you might have so far.
Agenda
The text was updated successfully, but these errors were encountered: