Closed jesbis closed 4 years ago
Yeah I think a big question is whether WinUI 3 will run on NET Core and if so, does that mean it gets the full API surface of NET Core even though there's the sandbox (e.g. can we use File not just StorageFile?)
I'd like to hear about WinUI/UWP and dotnet core 3.0.
Also, I'd like to hear if XAML Standard is in the works (winui and xamarin should use same xaml syntax)
Will it be recorded for watching after the fact?
Yeah I think a big question is whether WinUI 3 will run on NET Core and if so, does that mean it gets the full API surface of NET Core even though there's the sandbox (e.g. can we use File not just StorageFile?)
BTW I believe the Sandbox becomes optional, if you want an app to run on Hololens, Surface Hub Xbox, etc. Otherwise you should have access to the whole Win32 API surface if it's a Desktop only app.
Not sure what runtime will be recommended for Surface Neo and Surface Pro X :)
Thanks, keep the questions coming! We can definitely go over things like .NET Core plans, UWP sandboxing, etc.
We are planning to record so people can watch afterward, though it's TBD where else we'll upload it.
Thanks, keep the questions coming! We can definitely go over things like .NET Core plans, UWP sandboxing, etc.
We are planning to record so people can watch afterward, though it's TBD where else we'll upload it.
Mixer and YouTube would probably work, Channel9 seems to have become a hub for content stored elsewhere
Could you clarify the format of this call a bit more? It sounds like:
@kmgallahan updated the issue to include the agenda/format we're thinking of - is that clearer?
It's basically what you outlined 😊 Open to all, no registration required.
We'd like to cover issues/questions that come up ahead of time in this thread, but will probably also do some live q&a as time allows.
@kmgallahan To add to what @jesbis said, I'll say that I hope people aren't muted the whole time; one goal of these calls is to facilitate discussion and bring more of a community feel to it, instead of a "MSFT people talk at us for an hour"-type feel. We want it to have back and forth, and as long as it doesn't get out of hand where people are constantly talking over each other, I'd like to mix in questions in the midst of the subjects we cover and have an atmosphere of audible dialog at any time.
We're also going to be learning how to do this well--the first few attempts at this might be a bit of a cluster, and that's OK. :) Suggestions on how to run them, in addition to the content itself, are welcome!
More group conversation, less Windows Insider webcast. (not to say one is better than the other though)
@mdtauk Yeah. There's a place for both for sure. I'm hoping this has more of a conversation-y feel. We'll still have specific topics and we'll need a moderator to keep us from going too deeply down a rabbit hole, but I'm hoping that people feel free to engage and participate in the dialog alongside whatever topics we're covering.
What I'd like to avoid is how the Windows Insider live stream sessions tend to go:
The aimlessness and repetitive nature of the questions gets a bit old after watching 1-2 of the livestreams.
We're also going to be learning how to do this well
If I could suggest one single thing > please work out your audio/visual/hardware/streaming software/Mixer/other technical issues long before the stream starts. I don't even want to think about how many man-hours have been wasted waiting on technical issues with the Insider streams to get resolved...
@kmgallahan Great suggestions there. Yeah, the "repetitive" thing is good insight. (@jesbis, take notice of that point and let's think about how we can safeguard against that)
The point about technical issues is a good one too. We're pretty good at running Teams meetings internally here at Microsoft since that's how everyone does their meetings inside the company these days. However, we're not quite experts at doing these with a broad group of external folks; we might have to test-run this once or twice. We'll try to get it working reasonably well on the first shot!
@mdtauk Yeah. There's a place for both for sure. I'm hoping this has more of a conversation-y feel. We'll still have specific topics and we'll need a moderator to keep us from going too deeply down a rabbit hole, but I'm hoping that people feel free to engage and participate in the dialog alongside whatever topics we're covering.
Do you see this becoming a monthly thing? The dot Net team do design reviews for their APIs out in the open.
I'm really looking forward to this!
It would be helpful to hear an update on the winui3 roadmap. I am eager to try the new chromium-edge; I haven't yet heard of any preview of that control for win32.net or Uwp.net either. Also I'm very interested in data validation. There has been discussion about adding this into Uwp for several years and I'm hoping we will finally get something in winui3.
It may be helpful if you could start with introductions so we know what team(s) are on the call. I get confused by the boundaries between different teams- Winui, community toolkit, xaml tools, vs templates and compiler tool chains, etc. As one example of my confusion, I have no idea who owns compile-and-launch for Uwp- xaml in visual studio. I have had substantial trouble in the past while attempting to compile-and-launch my Uwp projects and libraries in a reasonable amount of time, for productivity sake. (It is multiple times slower to compile Uwp-xaml than wpf xaml for the same set of user controls.) Initially I was certain that the vs community feedback was the right place to report these concerns ... but they told me to come here.... However I don't find many other issues related to visual studio tooling ; so this doesn't seem to be the right place for it either.
Finally, I'd like to understand - even at a high level - what types of devs are most successfully using Uwp- xaml today. I get the impression that the primary audience is still the native c++ devs . It seems as if the .net and Enterprise devs are theoretically able to build apps with Uwp- xaml ... but wpf is hard to beat I'm terms of power and productivity. Sorry for the long comment. Maybe we will need more than one hour!
@mdtauk Monthly is the plan; last Wed of every month. (except not December lol)
I'm not sure we want to use this specific forum for design reviews for APIs; we've talked a bit about doing open reviews but I think that's a more formal thing that we'd want a bit more structure around. At least that's my initial thought at the moment.
Question for everyone: You all good with us starting on time for these? (as in, no later than 9:01 or 9:02 and we don't wait for a lot of folks to join late) I kinda want to set the tone of "we start on time" to maximize the time we have for actual content/dialog.
Edit: 9:01am refers to pacific time; obviously translate to whatever timezone you're all in. :)
I second @dbeavon's request, but specifically it would be great to get an overview of all the teams that touch WinUI in some way:
Question for everyone: You all good with us starting on time for these? (as in, no later than 9:01 or 9:02 and we don't wait for a lot of folks to join late) I kinda want to set the tone of "we start on time" to maximize the time we have for actual content/dialog.
Edit: 9:01am refers to pacific time; obviously translate to whatever timezone you're all in. :)
As long as there is a way to re-watch then people can catch up on things
@mdtauk Monthly is the plan; last Wed of every month. (except not December lol)
I'm not sure we want to use this specific forum for design reviews for APIs; we've talked a bit about doing open reviews but I think that's a more formal thing that we'd want a bit more structure around. At least that's my initial thought at the moment.
I wasn't suggesting that the development take place on video, just giving an example of how another open source project is using video. So you could try things out, and decide on how you want to make use of these "Team Huddles" to help all your work out!
Great initiative!
I was wondering if there will be any designers from the Fluent Design team as well. Would be nice to hear more what's coming next for Fluent (remember the Waves?) since it's a big part of WinUI.
Question: Can we use Win2D with WinUI and if not, is there similar powerful graphics such as Win2D or possibly full DirectX and OpenGL support for .NET Core 3 Desktop that uses WinUI?
One more question I had, is there a plan to advocate WinUI to both internal teams at Microsoft and external devs?
I noticed on Twitter someone from the dotnet team felt that there was no way to build modern UI using native Windows frameworks. He felt that the web was the only way to build a modern UI today. But he only included WinForms and WPF in his analysis, so he ignored WinUI and UWP.
In the spirit of One Microsoft, it would be great if there was a plan to create more unity between the dotnet team and the WinUI team.
Also, I'd like to hear if XAML Standard is in the works (winui and xamarin should use same xaml syntax)
Yes, big +1 for this. Would be great to see the Xamarin flavour more closely match WPF and WinUI. It drives me nuts going back and forth as I'm working on both platforms presently.
Will it be recorded for watching after the fact?
As much as I'd love to attend, I think it's unlikely given it is 2am in Australia at that time. Would definitely like to watch a stream the following day though.
In the spirit of One Microsoft, it would be great if there was a plan to create more unity between the dotnet team and the WinUI team.
More consistency and less electron would be :D
What's the status of AppWindow? Is it still being developed and will it come out of preview? It will only be for the UWP app model?
Sharing Gavin William's question from Twitter:
Can we get a template for WinUI in a C#/UWP application. Can we use WinUI with CoreApp?
My obvious question: are there any concrete/future plans of making WinUI cross platform, like what the Uno Platform does? Otherwise, is the plan NOT to make it xplat ever (so we at least know your intentions)?
Will Microsoft ever consider UWP/WinUI first class citizen (it's definitely not, at the moment, it doesn't even have .NET Core 3 or C# 8 support).
Are you going to reduce XAML verbosity by introducing more built in markup extensions, converters and behaviours that covers all frequent scenarios?
This is a great idea and will be exciting to see where it goes. I would suggest collecting topics ahead of the meetings and then only discussing the top items in each area:
-> Roadmap -> New Feature API/design reviews -> Open Issues (what bugs are top priority) etc...
I didn't see a main topic for bugs/open issues but I think that will be important to include in the conversation as well -- at least to prioritize.
Thanks for all the suggestions and questions so far! We're keeping a list of what people are interested in.
Question: if we don't get to everything in the first call (we probably won't since we only have an hour), would a written q&a summary thread be helpful?
We'll also keep topics in mind for future calls - e.g. we could have a Fluent Design guest expert join.
Question: if we don't get to everything in the first call (we probably won't since we only have an hour), would a written q&a summary thread be helpful?
I suspect a Q&A summary thread would end up getting very long and end up on lots of divergent conversations. An actual "Frequently asked questions thread" may be useful for those questions that do come up repeatedly, but I'd lock that thread to avoid random follow-ups.
I recommend continuing encouraging people to open new issues when they want to ask new questions. Having questions in the titles of individual issues will make them easier to manage, search, and point people to when duplicate questions are asked. The FAQ thread could even point to individual issues where appropriate.
Suggested questions: WPF parity issues -- when will this problem be mitigated? I'm still trying to finish the conversion of a large WPF app to WinUI/UWP but it has been delayed by the use of various functionality that exists in WPF but still has no equivalent nor replacement in WinUI. Improving feature parity with WPF would be a big help in the case of developers trying to convert large WPF apps and/or enterprise WPF apps to WinUI/UWP. It feels like the rug is pulled out from underneath you when useful functionality is provided and then later removed or otherwise made unavailable, without a replacement or new version being provided.
In the case of converting large enterprise WPF apps to WinUI, the difficulty is further compounded by the UWP sandbox restrictions. Actually the UWP sandbox is a wonderful thing and essential for the security of Microsoft Store, but it does also trigger a substantial disadvantage in the case of enterprise apps that are prevented from doing what they are required to do, because of the limitations of the UWP sandbox. These limitations make it time-consuming to develop workarounds and they delay the conversion of enterprise apps from WPF to WinUI. Can you give some details about how WinUI 3.0 may eliminate or at least mitigate this problem?
I'm also eager to hear any news about new versions of Edge-WebView OR WebView2/Chromium for WinUI/XAML. Is it possible to roughly estimate when a preview version of a WinUI XAML WebView2 Control will be made available?
C++ versus C#: Don't you find it a hassle to write in C++? Don't you wish that parts of WinUI could be written in C#? I abandoned C++ years ago and experienced a big boost in productivity when I switched to C#. Admittedly, since that time, some productivity problems in C++ have been mitigated, thus today C++ isn't as far behind C# as it was in the past. It would still feel like a step backwards if I reverted to C++.
I think C++ is the better option. Each has their own use-cases and this project is better off with the use-case of what C++ can provide vice C#. On that note, I noticed that SAL annotations were removed. Why? Static code analysis was far better before. Is there plan to implement GSL instead? SAL appears more mature but GSL should be used otherwise. Also, consider supporting libc++ for Linux support since we now have STL open-source under same license for portability.
@WSLUser -- Thanks for sharing but the content of my message was suggested questions intended for the Microsoft staff to talk about during the community call on Wednesday, not topics to be immediately debated. i.e. I was replying to what @jesbis said:
Please let us know and leave a comment with any topics or questions you'd like to hear about!
Yes, just wanted to voice my alternative opinion to the staff so they understand there are different viewpoints on the matter.
@verelpode Not sure if you're just looking for their personal language preferences, but C# isn't an option for WinUI because then apps like the Calculator with purely unmanaged code couldn't use it.
Separate C# WinUI packages would cause fragmentation, so best bet is to just put C# contributions in the Windows Community Toolkit.
The cross-platform development story becomes pretty important with Surface Duo on the horizon. A lot of people here are looking forward to somehow running WinUI/XAML on Android and iOS one way or the other. If you are able to announce anything in that direction, please don't hesitate to let us know :)
@lukasf sounds like something with React Native. Having WinUI on Android is something I am interested in as well.
If a cross-platform dev story it announced, it should better not sound like anything with HTML or JavaScript, or I will be closing the broadcast immediately ;)
@kmgallahan
Not sure if you're just looking for their personal language preferences, but C# isn't an option for WinUI because then apps like the Calculator with purely unmanaged code couldn't use it.
The WinUI team can still answer the question because if they really wanted to use C# then they could. It is an option in theory. Even an operating system (even including hardware drivers) could be written entirely in C# without any C++ code -- theoretically -- because C# does actually support pointers and has an unsafe
keyword. However, certain C# or CLR features might be switched off in the case of a low-level hardware driver written in C#. For example, garbage collection might be switched off when executing a driver, and it would operate more like .NET Native does (C# compiled to native code), not so much with a CLR/runtime.
Some people might claim that C# doesn't make C++ obsolete because C++ is still needed for low-level stuff such as code for a microcontroller or microprocessor instead of a computer. But no, such a claim would be inaccurate because actually C# is already running on microcontrollers! For example, look at Meadow and Netduino and the .NET Micro Framework. That's much more than a proof of concept -- that's a real implementation with real devices.
If there was a WinUI running on Android story, the Surface Duo could replace the AOSP inbox apps, with the ones from Windows. (Calculator, Alarms & Clocks, Voice Recorder, Camera, Photos, People, etc)
I am curious about whether WinUI team will officially support various cross-platform GUI frameworks (RN, Flutter, ...) to built over WinUI stack?
I am curious about whether WinUI team will officially support various cross-platform GUI frameworks (RN, Flutter, ...) to built over WinUI stack?
React Native for Windows will be built on top of WinUI
Windows.UI.*
to Microsoft.UI.*
?I REALLY REALLY want to know. PLEASE
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment-513326079
@Nirmal4G
Once local WinUI code has been stabilized, you can merge back into windows platform, so that system apps and LOB apps can take advantage of the new improvements, on every new windows release.
There aren't going to be any more UWP UI updates beyond security & critical fixes, per the roadmap:
The existing UWP Xaml APIs that ship as part of the OS will no longer receive new feature updates. They will still receive security updates and critical fixes according to the Windows 10 support lifecycle.
You either develop for the legacy UWP UI framework, or WinUI 3.0 - hence separate namespaces make sense, as they aren't the same thing.
But, we'll see what the devs have to say that they haven't already said here:
With WinUI 3.0 that isn't a scenario -- you can't mix and match OS controls with WinUI 3.0 controls. That only works with WinUI 2.x right now because those controls are add-ons to the OS (and we have a lot of awkward cases where we shipped the type in both places like NavigationView and TreeView causing ambiguity).
@kmgallahan
There aren't going to be any more UWP UI updates beyond security & critical fixes
You know, humans are people and people can tell WHITE lies.
The CShell Windows components use UWP XAML, Input and Composition. So, why (more accurately how) do they obselete it? More variants of the CShell (aka Windows 10X) are coming, It's a critical component of Windows.
Either they move the namespace to WindowsInternal.UI.*
or Windows.Internal.UI.*
inside the WinMD and keep the old one for compat reasons or just increment the contract version and make the WinMD private.
The current Public APIs are here: %WinDir%\System32\WinMetadata
Sure, we may not have access to the System UI framework within Windows 10 > 20H1. But all the cool stuff will be inside Windows.Internal.*
or WindowsInternal.*
namespaces, the files conveniently named inside System32
directory. Go ahead and look there, you'll be surprised.
It's like all over Vista again, where they move the good stuff (DirectUI) into Windows, then giving us the baseline (WPF).
@Nirmal4G
No one has said that UWP UI will be removed from the OS. UWP will have to stay in the OS for a very long time, since legacy apps (including OS apps and components) might still use it. The UWP APIs also won't have their namespace changed, since that would break all legacy apps. Everything stays as is now. Maybe in the long run, UWP UI APIs might be set to "deprecated". But since only WinUI will be further developed and evolved, Microsoft will pretty sure move their own important apps to WinUI as they are working on them. But it is not a problem if some apps or CShell components use WinUI and others use UWP. Both can exist in parallel.
@lukasf
I'm sorry if you don't understand.
What I'm saying is that they were not being deprecated, they are saying that's the case, but its not true. All I'm saying is that they could be more honest (open) about their decision and we might surprise them with our ideas/solutions.
@Nirmal4G They are being deprecated. Just because they are not removed does not mean they are not deprecated. Deprecated means you can still use it, but you should better use something different (usually something better).
And as you write it it sounds like UWP is the good UI stuff (which they hide from us like DirectUI) and WinUI is the bad UI stuff. The opposite is true: WinUI 3.0 when released will be much better than UWP UI, with more controls and more features, open source developed, and able to target lots of Windows 10 versions without forcing end users to upgrade. This is a major step forward, and I really don't see any reason to use UWP UI when WinUI is there.
@lukasf
I'm just saying, let there be one UI library by Windows Team for Windows and friends. That's all.
Just increase the contact version and introduce a store FrameworkDependency
msix/appx package similar to .NET Native framework, and we can all live happily ever after.
Everything you, they said but without changing namespaces.
@Nirmal4G Oh so the namespace change is what troubles you? Don't worry, when you switch to WinUI 3.0, you won't have to specify namespaces in XAML anymore. You can just use normal XAML names as you would with UWP XAML. The namespaces are only needed during transition, while you mix both WinUI and UWP UI in one app.
@lukasf
I know that. Still you have to change code-behind. I don't mind these at all. A good namespace change is always welcome. But here, we don't even need that change. It'll work as it is.
My Q is, Why the namespace change? Is it political (OSS / Windows Souce) or Technical. Please Explain in detail.
Because, I built a WinRT Component duplicating the standard namespaces and no, they don't clash if referenced properly.
Update:
Thanks everyone who was able to call in to our first community call! We really appreciate the interest, questions and feedback.
Recording download link
Temporary download link to the first call recording (OneDrive) - we're working on a better streaming/hosting approach and will update this link later.
After calling in or watching, please do fill in the survey to let us know if you have any feedback on the format or content:
https://aka.ms/winuisurvey
Hi everyone,
The WinUI team is planning to host a regular "community call" (via Microsoft Teams) and we'd like to invite you to suggest topics and call in!
Download a recurring calendar invite here (.ics):
https://aka.ms/WinUICommunityCall
We'll hold the first one next week on Wednesday, October 30 (9am PDT/12pm EDT/16:00 UTC).
This will be a very informal online call directly with members of our engineering team via Microsoft Teams.
Anyone and everyone is welcome! No pre-registration is required.
Assuming we get enough interest then each month we can discuss and answer questions about Windows app development with WinUI including our roadmap, new features, and your feedback and suggestions.
Main topic areas could include:
Agenda for next week's call:
We'll have a small handful of WinUI team members and we'll project a screen + video feed from a conference room via Teams.
Anyone else is welcome to call in and watch/comment live!
Format will likely be:
Interested?
Please let us know and leave a comment with any topics or questions you'd like to hear about!
We can't promise to cover everything but we'll do our best next week or in a future call.