我们能谈谈对控件和默认值中可为空数据类型的支持吗？ 例如，有DatePicker返回 DateTimeOffset 和CalendarDatePicker返回 DateTimeOffset?。

• 为什么其中一个可以为空，而另一个则不是？ 这是因为 DatePicker 是使用 Windows 8 时间范围内的早期 API 开发的吗？
• 我们应该考虑在控件中添加一个配置属性来允许/不允许 null 吗？
• 是否应该为 NumberBox 等新控件考虑DefaultValue属性，是否应该将 NaN 保留为默认值，还是应该切换到具有默认值的可空双精度值？
• 返回和支持可空值是否存在 WinRT/OS XAML 限制，这会阻止使 NumberBox 的Value属性可空？ 如果是这样，CalendarDatePicker 是如何实现的？
• 这与#1721 和#1708 中的 NumberBox 讨论直接相关

另外，解决 NumberBox 上不依赖于 WinUI 3.0 的未解决问题的路线图是什么？ 最好在 WinUI 2.4 周围开始使用此控件，而不必等待更长时间。 在我看来，它还没有完全成熟，我对将其引入生产应用程序感到不舒服。

我想讨论的另一个有趣的想法是：既然 WinUI 3.0 将开源，Microsoft 将制定什么政策来破坏更改？

过去，Microsoft 几乎从未进行过重大更改。 这通常是一件好事，直到几年（或 10 年）后所有的杂物都堆积起来。 它也不是开源项目的标准。 例如，最终应该为 ListView 淘汰 ListBox，为 ContentDialog 淘汰 MessageDialog，等等。我相信 API 中也有很多更好的小清理。

我知道企业讨厌变化——这是有充分理由的。 还必须有一个相对简单（功能等效）的替代品，以便直接移植到新的 API。 这需要根据具体情况进行评估并做出判断。

我想知道我们是否可以建立允许重大更改的主要版本（例如 WinUI 4.0）。 这将使项目继续发展，而不必忍受过去的所有错误。 本质上，微软已经决定通过 .NET 5 来实现这一点，将其基于 .NET Core 并放弃完整的 .NET Framework。

一旦讨论过，这可能会很好地记录下来。

根据自上次电话会议以来取得的进展，团队实际认为 WinUI 3 何时可以发布：

• 构建 2020（4 月至 5 月）
• Ignite 2020（10 月至 11 月）
• ~2021

此外，您在 .NET 团队中的工作对将新的 AOT 解决方案和 .NET 5 组合在一起的依赖程度如何？

最后，Windows 方面是否有压力使其为 Windows10X 版本做好准备和/或在此之前让开发人员制作专门的应用程序？

是否有/应该有一个工具可以轻松地将 WinUI 2.X 项目转换为 WinUI 3.0（因为手动执行此操作对于大型项目来说可能需要大量工作）？

房间里的大象 - WinRT (#1856)

房间里的大象 - WinRT (#1856)

非沙盒应用模型即将推出 - 将以与 WPF（包括 Win32 API）相同的方式运行，但可以访问现代 WinRT API，以及使用在 Direct X 12 上运行的新 XAML 的开源 UI 和控件。

非沙盒应用模型即将推出 - 将以与 WPF（包括 Win32 API）相同的方式运行，但可以访问现代 WinRT API，以及使用在 Direct X 12 上运行的新 XAML 的开源 UI 和控件。

哇。 哇哇！！！！

这太不可思议了！ 我们是否有这方面的预计到达时间，会在电话会议中讨论吗？

真是太棒了！

非沙盒应用模型即将推出 - 将以与 WPF（包括 Win32 API）相同的方式运行，但可以访问现代 WinRT API，以及使用在 Direct X 12 上运行的新 XAML 的开源 UI 和控件。

哇。 哇哇！！！！

这太不可思议了！ 我们是否有这方面的预计到达时间，会在电话会议中讨论吗？

真是太棒了！

这是我们了解 WinUI 的第一件事。 ETA 是今年的，我怀疑将在 //Build/ 上给出一个明确的日期 - 但请在电话中随意询问。

https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md

@jtorjo请参阅WinUI 路线图。 另请参阅https://github.com/microsoft/microsoft-ui-xaml/issues/1045了解更多信息（例如 VS 项目模板）。

@mdtauk @Felix-Dev 我会重新阅读这些文档。 我确实记得之前问过这个问题 - 只要我可以从我的（非沙盒）应用程序中轻松使用 win2d，我就会非常高兴！

@jesbis很抱歉问这个

我们正在为今天晚些时候的明天通话设置信息 - 我将在几个小时内发布路线。

延迟是因为这是我们第一次使用新的广播系统 - 在此之后它应该会更顺畅并早点准备好🙂

我只是有一个有趣的想法（无论如何对我来说）。

浏览今天的 ASP.NET Community Standup 直播，我看到基本上有 4 位 MS 开发人员在做直播，尽管它更像是一个技术演示。 我也偶尔会在 Twitch 上收听@csharpfritz ，他在现场编码会议上

所以我的想法是 - 在 WinUI 3 发布并且代码库（或大部分）都是开源的之后，是否有团队成员偶尔会在 WinUI 上直播他们的一些工作？

这将是一个增加 WinUI 曝光率的好机会，可以帮助人们随意探索代码库，并且可以不时提出问题。 〜我不建议一直完全参与聊天，因为这会适得其反，但也许偶尔会进行问答。

我不知道 MS 对这类事情的政策是什么，尤其是在工作日。 听到你的想法会很有趣。

这是明天的 YouTube 直播活动链接！

https://youtu.be/MXTVqgB4rW0

感谢到目前为止所有的评论和问题！ 如果我们没有时间，我们将尝试了解所有内容，或者跟踪跟进。

指南中是否有关于 ui 的性能/fps 的内容？ 我对现代 Windows 10 的最大抱怨之一是，在像 Surface Book 这样的机器上，你在高 DPI 显示器上获得了一些糟糕的性能，当你结合透明度和额外的显示器时，情况会更糟。 这可能是不可能的，但是这里有没有考虑它的流动性和性能如何，尤其是在这些条件下？

请考虑提高无边框/透明窗口的优先级（a la https://github.com/microsoft/microsoft-ui-xaml/issues/1247）。 这是应用程序的 WinUI 采用阻止程序，例如我们的。

抄送： @crutkas

请考虑提高无边框/透明窗口的优先级（a la #1247）。 这是应用程序的 WinUI 采用阻止程序，例如我们的。

抄送：@crutkas

这可能需要将顶级窗口元素添加到具有属性的 WinUI Xaml，类似于 WPF。 第1323章

了解更多关于 WinUI 的“窗口化的未来”会很好 - 有很多相关的请求至少可以讨论/解决。

可能以前问过。

对我来说，始终是代码可重用性的问题。
这导致两个问题：

1. .NET Core 3 和 C# 8.0 支持即将到来吗？
2. 我们是否会看到 UWP/WinUI 团队采取进一步措施来简化 Uno 平台应用程序的开发？

另一个问题，我们什么时候会看到 UWP 支持的 WPF 中缺少的位？

可能以前问过。

对我来说，始终是代码可重用性的问题。
这导致两个问题：

1. .NET Core 3 和 C# 8.0 支持即将到来吗？
2. 我们是否会看到 UWP/WinUI 团队采取进一步措施来简化 Uno 平台应用程序的开发？

另一个问题，我们什么时候会看到 UWP 支持的 WPF 中缺少的位？

.NET Core 代码应该适用于两者，因此 WPF 应用程序只需要更改 UI Xaml 和 UI 代码。

UWP 应用程序在 WinUI 3.0 的命名空间更改后应该可以正常工作 - 打破沙箱可能需要更多的工作，细节仍然未知。

WPF 缺失位尚未得到确认，但我提出了一个问题。 第719章

@weitzhandler

尽管它不受官方支持，并且并非所有 C# 8 功能都可以使用，但您已经可以将大部分 C# 8 与 WinUI/UWP 结合使用。 见这里。

我这样做并且没有遇到任何问题。 “默认接口成员和索引和范围”似乎是唯一缺少的部分，尽管我还没有尝试过所有内容。

只是放大了 kmgallahan 所说的关于使用 C# 8 的内容。我一直在使用许多新功能，但真的想要默认接口​​成员，但尚未实现。

谢谢各位。
如果我仍然可以补充，旧的 csproj 类型也有点烦人。

@jesbis

我刚刚在 XAML 控件库中打开了这个问题。 如果您愿意，可以在通话期间讨论一些事情。

谢谢，我们会尽力回答所有问题！

指南中是否有关于 ui 的性能/fps 的内容？

@ryvanvel我们在这里有一些性能指导：

https://docs.microsoft.com/windows/uwp/debug-test-perf/performance-and-xaml-ui

以及其他一些可能有帮助的博客文章和视频，例如：

https://blogs.windows.com/windowsdeveloper/2015/10/07/optimizing-your-xaml-app-for-performance-10-by-10/

https://channel9.msdn.com/Events/Build/2015/3-698

https://channel9.msdn.com/Events/Build/2017/P4173

据我所知，这个错误一直存在于 Windows 10，我希望它早点得到解决： https :

不幸的是我将无法按时收听，会有录音吗？

编辑：通话录音可以在这里找到： https :

@jesbis在这里：

这是明天的 YouTube 直播活动链接！
https://youtu.be/MXTVqgB4rW0

跟随 YT 链接，看起来它只会在这个小时结束时开始，比正常时间晚一个小时，是真的吗？

@weitzhandler开始时间在帖子的顶部。 这也只是第三次调用，所以“常规”是一个延伸。

@weitzhandler我很确定到目前为止所有三个电话都计划在太平洋时间上午 9 点开始。

谢谢两位，抱歉打扰了。 再见。

我很想知道 Chromium 驱动的WebView2是否也会从当前的WebView公开一个类似WebResourceRequested的事件，让开发人员过滤掉单个 Web 请求。 我在我的一个应用程序中非常依赖该特定功能，我想知道新控件是否仍然存在，并以相同的方式工作。

感谢大家的辛勤工作！ 😄🚀

有没有生成PDF的工具？ Win2D 已经有很多了不起的工具，从CanvasRenderTarget生成 PDF 的能力将是一个很好的补充。

没明白 - 如何安装 vsix？ 在哪里下载？

也许只是我一个人，但我对今天的电话感到失望。 请包括更多的技术人员。 PM 应该保持讨论的重点并按计划进行，但将响应委托给专家（正如在最后所做的更多）。

我猜这次电话会议上的每个人都是开发人员，我们需要了解和讨论细节。 PM 专注于非常基本的主题，无法深入细节。 例如，电话会议开始时关于文档/WebView/ProgressRing 的讨论在概念上很好，但非常基本，我认为它对我们没有用。 我们已经使用 XAML 多年/几十年了，您正在与专业观众交谈（使演示文稿适应观众很重要）。

@SavoySchuler释义你基本上是说告诉我们我们如何使用控件，包括我们的公司和我们的应用程序。 你需要这个来区分材料需求和很好的需求。 这有助于您优先考虑功能上的资源。 您需要以不同的方式考虑以下两件事：

1. 特点——在这种情况下，你说的基本正确
2. 错误/问题 - 在这种情况下，不，您不需要社区为您提供示例来帮助确定优先级。 在交付任何产品时，质量是您的第一要务。 我们告诉你这些错误，你说，嗯，是的，这是一个很好的。 证明你需要修复它。 这是一个错误。 也许您从未将应用程序交付给消费者？ 任何错误的小事都会影响您的形象和感知，这是公司最有价值的部分。 App行业竞争非常激烈。

一旦社区报告了错误，您应该安排修复它们。 停止发布没有计划修复它们的不完整控件。 这听起来很熟悉——这就是几年前 UWP 发生的事情。

在电话会议中，我两次提到窗口化，并提到：

• 这实际上是针对 WinUI 3 进行的（尽管问题已被冻结 https://github.com/microsoft/microsoft-ui-xaml/issues/1247）
• 功能跟踪项目（昨天更新）（https://github.com/microsoft/microsoft-ui-xaml/projects/4）只跟踪 WinUI 2 的东西？？？

我们可以在这里澄清一下吗？ 是否还有其他位置可以查看 WinUI 3 backlog？ 对于计划目的而言，我们知道即将发生的事情和不会发生的事情非常重要。 谢谢！

@SavoySchuler @jesbis和可爱的 WinUI 团队的其他成员，我个人要感谢您的出色工作和巨大努力，并告诉您我非常感谢让 WinUI 如此出色并回答我所有的问题。

非常感谢所有能够收听的人！

再次对音频和 Teams 问题感到抱歉——我们认为我们发现了一个硬件问题，希望能在下个月解决所有问题。

录音现在也为无法做到的人提供现场直播。

我们正在查看问题，并会尝试解决我们在此线程中遗漏的任何问题。

一些问题追赶：

有没有生成PDF的工具？

@MuziburRahman

我们没有时间为 WinUI 3.0 RTM 解决这个问题，但我们正在使用 #672 在待办事项中跟踪此问题 - 请随时对该问题添加评论，了解您将如何使用它！

怎么安装vsix？ 在哪里下载？

@hannespreishuber

生产应用程序的 WinUI 2.x 使用说明在这里： https ://docs.microsoft.com/uwp/toolkits/winui/getting-started

安装和试用 vsix 的 WinUI 3.0 Alpha 说明如下：
https://aka.ms/winui/alpha

也许只是我一个人，但我对今天的电话感到失望。 请包括更多的技术人员。 PM 应该保持讨论的重点 [...] 我们已经使用 XAML 多年/几十年了，您正在与专业观众交谈（使演示文稿适应观众很重要）。

@robloo感谢您对此的反馈。 如果每个人都感兴趣的话，我们可以包括更多的开发人员并对特定主题进行更深入的研究，以备将来的电话会议 - 我们不想在第一次电话会议上尝试这样做，因为已经有一段时间了，我们想做一个一般性的捕获 -向上。

过去我们也收到过反馈，有时我们会变得过于技术化和深入，因为很多观众对 WinUI 还不是很熟悉——所以我们也在努力平衡这些反馈。

另外，如果有帮助的话：我们开发平台团队的许多 PM 都是超级技术人员，并且有为主要平台和真实应用编写生产代码的经验。 他们中的一些人以前是微软和其他公司的全职开发人员。 我们仍然作为 PM 一直在写代码，这不是我们唯一的关注点 🙂

最后，关于错误和质量：质量对我们来说非常重要，我们在错误、测试和质量基础设施上花费了大量时间。 您可以在 WinUI 2 的提交日志中看到质量修复与新功能的比率，一旦它开源，您将能够看到 WinUI 3 的相同情况。也就是说，没有任何主要代码库是无错误的，我们始终必须平衡业务优先级。

如果控件看起来不完整，那么请为他们打开问题。

在电话会议中，我两次提到窗口化，并提到：
这实际上是针对 WinUI 3 进行的（尽管问题已被冻结 #1247）
功能跟踪项目（昨天更新）（https://github.com/microsoft/microsoft-ui-xaml/projects/4）只跟踪 WinUI 2 的东西？？？
我们可以在这里澄清一下吗？ 是否还有其他位置可以查看 WinUI 3 backlog？ 对于计划目的而言，我们知道即将发生的事情和不会发生的事情非常重要。 谢谢！

@riverar该项目板目前适用于 WinUI 2，因为它是当前存储库中的唯一代码。

对于必须等待 WinUI 3 才能正确解决的问题，我们使用need-winui-3标签，但我们还没有对 WinUI 3 工作进行公开跟踪。

我们将继续发布主要项目的功能建议 - 例如单独的规范存储库中的 Chromium WebView 规范：

https://github.com/microsoft/microsoft-ui-xaml-specs/blob/master/active/WebView2/WebView2_spec.md

一旦我们能够开源 WinUI 3 Xaml，我们就可以开始将跟踪转移到 GitHub，但是由于各种原因（我们有很多需要与其他操作系统组件开发团队密切交互等）

我可以说，虽然大多数标记的功能建议不会在最初的 3.0 版本中得到解决——我们的主要关注领域是：

• 使 WinUI 与操作系统分离并单独发货
• 开源 Xaml 框架
• 创建良好的 WinUI 桌面应用程序开发体验（win32 使用、打包、窗口化等）
• 启用 Windows 10X
• 启用 .NET Core/5 + WinUI 应用程序

我们不想通过尝试同时进行大量额外的新功能开发来延迟或破坏它的稳定性。

随着我们在桌面/窗口支持等大领域取得具体进展，我们将向 repo 发布提案和更新。

一旦我们能够开源 WinUI 3 Xaml，我们就可以开始将跟踪转移到 GitHub，但是由于各种原因（我们有很多需要与其他操作系统组件开发团队密切交互等）

是否可以公开列出这些内部工作项目，即使它们显示为具有某些通用名称（如Internal Issue）的空白条目？ 看到这些从 To Do、In Progress 到 Complete 的移动，表明整个项目在某种程度上取得了进展。

我可以说，虽然大多数标记的功能建议不会在最初的 3.0 版本中得到解决——我们的主要关注领域是：

• 使 WinUI 与操作系统分离并单独发货
• 开源 Xaml 框架

这当然是努力的核心，但有可能解决当前实现的各种问题或问题，因为它是从操作系统代码中解脱出来的。

• 创建良好的 WinUI 桌面应用程序开发体验（win32 使用、打包、窗口化等）
• 启用 Windows 10X

这对于正确处理至关重要，并且需要将这两件事交到用户和开发人员手中，并以开放的心态接受反馈。 这也很困难，因为应用程序运行时和应用程序模式不属于这个 WinUI 团队，因此需要将反馈过滤到负责他们的人。

• 启用 .NET Core/5 + WinUI 应用程序

当前本机支持以 C++ 代码和 Win32 API 的形式出现 - 但这是否意味着任何 C# 开发人员都需要以 .NET 为目标？ 非沙盒应用模型是否允许在没有 .NET 的情况下进行 C# 编码？

我们不想通过尝试同时进行大量额外的新功能开发来延迟或破坏它的稳定性。

随着我们在桌面/窗口支持等大领域取得具体进展，我们将向 repo 发布提案和更新。

没有 CoreWindow（这将是 UWP 唯一向前发展） - 窗口化是从第一天起就需要准备的东西之一。 WPF 在 XAML 中有一个 Window 对象，它处理控件、视觉样式、透明度等。它处理调整大小、最小化等。较旧的 Win32 框架需要手动绘制表面，这对于 XAML UI 来说不是一回事 - 那么如何弥合这种差距?

这是在我们甚至开始使用双屏设备之前，以及非 UWP 应用程序模型和窗口设置将如何适应这种情况。

是否可以公开列出这些内部工作项目，即使它们显示为具有某些通用名称（如内部问题）的空白条目？

除了代码之外，我们的目标绝对是将我们的流程（包括问题跟踪）迁移到开源。

首先，我们有一个用于高级跟踪的WinUI 3.0 里程碑，随着我们将 WinUI 3 Xaml 代码迁移到开源，我们还将在该里程碑中打开更多“功能级”问题。

但是，这不会立即包括我们所有的 WinUI 3.0 日常开发任务 - 作为参考，我们目前正在跟踪 2020 年价值数千天的相关开发工作，但我们还没有准备好移动所有我们今天对 GitHub 的超细粒度跟踪。 不过，随着时间的推移，我们会做到这一点，就像我们在 WinUI 2 中所做的那样。

因此，我们将从功能级别的问题开始（例如到目前为止已经开始的问题 - 例如 WebView），并将随着时间的推移将我们的流程完全迁移到 GitHub。

当前本机支持以 C++ 代码和 Win32 API 的形式出现 - 但这是否意味着任何 C# 开发人员都需要以 .NET 为目标？ 非沙盒应用模型是否允许在没有 .NET 的情况下进行 C# 编码

您是在询问 .NET Native，还是根本没有 .NET？ 从技术上讲，我认为 C# 规范作为一种语言不依赖于 .NET，但我们目前没有计划将其转换为 C++ 或类似的东西。

没有 CoreWindow（这将是 UWP 唯一向前发展） - 窗口化是从第一天起就需要准备的东西之一。 WPF 在 XAML 中有一个 Window 对象，它处理控件、视觉样式、透明度等。它处理调整大小、最小化等。较旧的 Win32 框架需要手动绘制表面，这对于 XAML UI 来说不是一回事 - 那么如何弥合这种差距?

@marb2000正在

这是在我们甚至开始使用双屏设备之前，以及非 UWP 应用程序模型和窗口设置将如何适应这种情况。

需要明确的是，WinUI 3 不会将所有 win32 桌面带到 HoloLens 等其他平台：通用应用程序和 API 仍将是针对多个设备的方法。

发得太早了。 完整评论：

@robloo - 我想首先同意你的很多观点，我感谢你在我们成长的痛苦中与我们一起承受。 我对我们所有的技术问题都非常漫不经心，我​​没有像我希望的那样处理这个问题。 请允许我在这里再试一次：

章程和资源

我知道讨论这样的任何话题永远不会流行，但我相信透明度，并希望作为社区的您坦率地谈论我们面临的挑战，以便您可以参与讨论，帮助我们决定如何解决这些问题. 这个特殊的挑战集中在时间和资源资产的划分上。 我们的团队分为三个主要计划：

1. 推进 WinUI 2
2. 交付 WinUI 3
3. 开源 WinUI 3

如您所知，我们坚定地选择了 2 和 3，因为 A) 这些是耦合目标，B) 开源 WinUI 意味着每个人都可以不再被我们团队有限的资源所阻碍，因为 WinUI 最终将有权接受社区拉取请求。

如果我们拨过向前目标2和3到一个地步，WinUI 2是社区成员服务下，我们可以有一个谈话，我们是开放的设置优先级。 只知道解决我们积压工作中的所有错误会使 WinUI 3 的上市延迟约 6 个月。 如果我们改为优先考虑 2 和 3，它们不仅开源 WinUI，而且将其与我们庞大的 Win32 开发人员群的相关性扩展，我们将能够利用开源社区和我们团队的力量清理积压的错误和功能请求全心全意支持我们。 为此，我们目前的基本原理是，方法计划不仅可以更快地推动该平台向前发展，而且可以更全面地推进。 当我请您帮助我们对错误进行优先级排序时，问题不是“它们是否足够重要以供我们的团队解决？” 而是“这比早点开源 WinUI 重要吗？” 在现状下，我们确实有一部分开发人员致力于推进优先级 1，您可以了解他们对我们的提交历史和活跃问题的影响，但他们仍然需要在该目标内确定优先级。 这种“告诉我们这对你有多重要”的概念确实帮助我们过滤需求（例如，我的产品被阻止，我等不及 WinUI 3）与细节（例如，我注意到这个技术错误但没有现有的开发被阻止，因此它可以等待 WinUI 3）。

我想明确说的另一件事是，所有用于归档 WinUI 2 错误、填写功能请求等的工作都不会_ _ 丢失在我们身上。 当 WinUI 3 发布时，我们将有一个重要的团队子集被释放，以在授权社区提交代码的基础上返回推进平台的工作项目。 这意味着现在我们正在准备一个积压工作，我们团队的全部力量将在我们现有的 UWP 社区以及很快的 Win32 的帮助下解决这个问题。

需要注意的另一件事是，当我们将代码从操作系统迁移到 WinUI 3 时，我们正在采取措施尽可能简单地清理背后的代码。 这意味着如果在 WinUI 3 中解决某些功能添加和错误修复将需要更少的时间和精力。

数字框

特征

让我们回到 NumberBox。 您说 V1 是所需功能的子集，这实际上是正确的。
由于依赖输入验证（顺便说一下，在 WinUI 3 alpha 中处于预览状态），计划中的 V1 功能被推迟到 V2。 我们试图通过在规范中承认我们认为应该成为 V1 的所有内容（此处）来完善我们的规范，并计划通过 WinUI 3 V2 版本的控件完全实现这一承诺。

通过拥抱开源精神，我的愿望（请告诉我这样做是否有误）是完全喜欢尽可能快地发布可靠、有用的代码并逐步构建功能集。 在应用程序中，这意味着更愿意在 WinUI 2 中发布我们_大部分_完整的 V1，并像在 WinUI 3 中一样，使用带有输入验证的全功能版本进行跟进。

错误

正如@jesbis所说，没有任何代码库是没有错误的，但质量对我们来说绝对是@jesbis指出，您可以在 WinUI 2 的提交日志中看到质量修复与新功能的比率，一旦它开源，您将能够看到 WinUI 3 的相同情况。

我仍然致力于使用 NumberBox 帮助解决这些错误，并且我将剩下的时间用于回应开放的问题、错误和我能够成为资产的问题。 下周我也会留出一天。 请在 Twitter 上向我发送问题或在 repo 上与我互动。

下一步

对我们来说，开源是作为团队成员拥抱社区的承诺，就像他们坐在我们雷德蒙德的办公室里一样。 我们在听。 让我们一起讨论这些决定，这样我们就可以作为一个大团队专注于构建很棒的东西。 🙂

我们 ❤️ WinUI

通过拥抱开源精神，我的愿望（请告诉我这样做是否有误）是完全喜欢尽可能快地发布可靠、有用的代码并逐步构建功能集。 在应用程序中，这意味着我们更愿意在 WinUI 2 中发布我们大部分完整的 V1，并像在 WinUI 3 中一样，发布带有输入验证的全功能版本。

这可能只是我，但我觉得虽然尽快发布代码很重要，但在发布任何东西之前应该解决某些类型的问题，例如 #1846 是应该在发布 V1 和那里之前解决的问题也可能是其他一些人。

@yaichenbaum我本可以在那里更好地选择我的话。 🙂

如果 AD 是 _must have_ features 并且 EH 是 _nice to have_ features，我的首要任务是将 AD 排除在外，并尽可能增加 EH。

我们与验证合作伙伴一起在预览分支上登台的原因是在控件被推送到稳定版本之前捕获像 #1846 这样的错误。 对不起，我们把球丢在了这个上，我会尽快与@teaP 合作，看看我们能多快解决这个问题！ 🙂

在通话中的某一时刻提到 WinUI 应用程序将允许通过 AppDomain 进行沙箱操作。

有人能谈谈 WinUI 3.0+ 将如何定位 Capabilities 与 AppDomain 以进行应用程序隔离和资源控制吗？

此外，我对 .Net Core 的最后一次了解，对 AppDomain 的全面支持并没有发生。

也许我脱节了，但是您是说 .Net 5 将拥有完整的 AppDomain 支持吗？

感谢您今天组织这次电话会议！

有人能谈谈 WinUI 3.0+ 将如何定位 Capabilities 与 AppDomain 以进行应用程序隔离和资源控制吗？

对不起，如果通话中不清楚，但我在谈论AppContainer ，而不是 AppDomain 。

啊，好的，谢谢杰西的澄清。

首先感谢@SavoySchuler和@jesbis （以及WinUI 团队的所有其他成员）组织今天的社区电话会议！ 虽然有一些技术上的困难，但这次电话非常有见地！！！

正如@jesbis提到的，跟踪 WinUI 3.0 请求的工具和功能存在问题。 将 WinUI 2.x 到 3.0 转换工具的请求拆分为一个单独的问题以便于跟踪会更好吗？ 还有已经有计划了吗？ 是否有计划将该工具开源，以便其他开发人员可以帮助开发它？

另一个更普遍的问题（也适用于其他非 WinUI 团队成员）是关于贡献。 目前是否有任何障碍阻止人们做出贡献？ 更好的贡献者入门指南会有所帮助吗？

在我看来，如果你开始为项目做贡献，VS 项目可能会有点压倒性，而且没有太多关于如何开发、应该使用哪个测试项目等等的文档......

也许这方面的改进会让人们更容易做出贡献😅

WinUI 3.0渲染层是怎么做的？ 是直接利用D3D11、D2D、抽象层还是什么？ 它是否具有软件渲染层或为此使用 D3D WARP？

@chingucoding

我将重复我刚刚在这里提出的观点：

• 永远没有使用过 lang
• 不知道 WinUI 3 版本的后台发生了多少代码改动会覆盖今天所做的更改
• 无法访问大量需要和/或极大地帮助解决问题的源代码

编辑：我举个例子。 #1555 和 #1849 似乎是核心控件 (TextBox) 的主要问题，它们在多任务处理时阻止了文本输入和选择。

它们在我应该解决的重要问题列表中名列前茅，但我不知道从哪里开始。 我也不知道我想要/需要逐步调试的代码是否可用。

@萨沃伊舒勒

如果我们在目标 2 和目标 3 上过于领先，以至于 WinUI 2 无法为社区成员提供服务，我们可以进行对话，并且我们愿意重新确定优先级。 只知道解决我们积压工作中的所有错误会使 WinUI 3 的上市延迟约 6 个月。

我当然明白。 然而，我认为 NumberBox 在这里有点不同，我当然不是说我们应该关注所有错误。 现在我只讨论 NumberBox 的上下文。 虽然肯定还有一些其他明显的问题需要解决。

NumberBox 是为 WinUI 2.3 新开发的控件，而不是每个人此时都必须接受的旧控件。 为什么我们不能正确地开始呢？ 这在很大程度上是对新开发模式的试金石。

如果 AD 必须具备功能，而 EH 拥有功能也不错，那么我的首要任务是将 AD 排除在外，并尽可能地逐步添加 EH。

我完全同意你的看法。 但是您必须了解功能和错误之间的区别。 我担心您只考虑 Microsoft 的资源/人力。 但是，您是否考虑过应用程序开发人员在尝试解决控件中的错误时浪费了无数时间？ 从源头上修复这些问题要高效得多，而且确实有助于对平台/工具的感知。

我想明确说的另一件事是，我们不会丢失所有用于归档 WinUI 2 错误、填写功能请求等的工作。 当 WinUI 3 发布时，我们将有一个重要的团队子集被释放，以在授权社区提交代码的基础上返回推进平台的工作项目。

微软在发布不完整的软件，然后在有机会完成最后一个之前转移到下一个最新和最伟大的技术方面有着非常糟糕的记录。 请原谅我怀疑你的承诺。

让我们回到 NumberBox。 您说 V1 是所需功能的子集，这实际上是正确的。
...通过拥抱开源精神，我的愿望（请告诉我这样做是否有误）是完全喜欢尽可能快地发布可靠、有用的代码并逐步构建功能集。

在功能方面与您完全相同。 虫子不一样。 您需要以不同于功能的方式解决错误，并为它们提供更多资源。 发布一个像 NumberBox 这样的全新控件，然后说在一年后你不能投入资源来修复错误，这看起来很糟糕。

我要求您解决不依赖于 WinUI 3.0 的控件 V1 中的错误。 有些是相当基本的，有些则是设计中的明显错误（例如 NaN 使双向绑定数据崩溃）。 一旦您承诺发布功能/控件，您就必须迅速努力关闭错误。 当软件首次广泛发布时，总是会出现错误，您只需要计划资源即可快速修复错误 V2（就像我们其他应用程序开发人员一样）。 由于我们同意质量是重中之重，请先解决 NumberBox 的以下问题，然后再进行其他操作。

1708 - 占位符文本对于控件的任何形式使用以及规范中已有的基本功能之一都是绝对必需的。 如果这确实已为 NaN 修复，我们应该关闭它。 空支持是下面的不同主题。

1721 - UWP 的一个大问题是它对某些控件中的数据绑定的支持不完整。 许多应用程序开发人员多年前投资于 MVVM 设计，然后尝试跳转到 UWP 控件，发现仅部分支持数据绑定。 这是一个巨大的痛点，考虑到 MVVM 对微软最佳实践的重要性，这是不可接受的。 旧的 Windows 开发人员工具团队永远不会支持这一点——这是 Windows/本地思维。

1839 年 - 这里的基本内容。 这些只是控制模板中的基本错误，必须修复。 没有理由。

1846 - 我们以前在许多其他控件中遇到过这个问题。 为什么现在没有一个发布清单来测试这个？ 同样，需要修复的基本内容。 它会影响使用此控件的所有应用程序的可用性。

1852、#1853、#1854 - 同样，这些并不过分复杂，只是在第一个实现中被遗漏了。 但是，法律要求支持在某些地区销售或为政府开发的软件的可访问性。 作为平台，您应该立即修复此问题，以便应用程序开发人员可以使用该控件。 再说一次，我不应该和你争论这种事情，这是基本的东西。

需要注意的另一件事是，当我们将代码从操作系统迁移到 WinUI 3 时，我们正在采取措施尽可能简单地清理背后的代码。 这意味着如果在 WinUI 3 中解决某些功能添加和错误修复将需要更少的时间和精力。

在高层次上理解。 但是，解决上述问题不会将 WinUI 3.0 延迟 6 个月。 它们也不依赖于 WinUI 3.0 来解决（可能除了 #1721）。 您通过发布 NumberBox 而不是坚持使用它来关闭第一轮错误，从而开创了一个危险的先例。 您应该已经通过 UWP 本身学到了这一课。

也许该领域的改进会使人们更容易做出贡献

愿意贡献。 不喜欢使用 C++/WinRT，当然也没有资格接触我所见过的代码库。 如果控件是由 C# 管理的，您将有更多的贡献。 我理解为什么架构是这样的，但后果之一是社区贡献减少。 我们在这里不是系统开发人员，我们是最终用户应用程序开发人员。

回复：贡献：

另一个更普遍的问题（也适用于其他非 WinUI 团队成员）是关于贡献。 目前是否有任何障碍阻止人们做出贡献？ 更好的贡献者入门指南会有所帮助吗？
在我看来，如果你开始为项目做贡献，VS 项目可能会有点压倒性，而且没有太多关于如何开发、应该使用哪个测试项目等等的文档......
也许该领域的改进会使人们更容易做出贡献

没有什么可以阻止人们为 WinUI 2 做出贡献，这是当前存储库中的代码库。 如果您想要解决 WinUI 2 问题，请告诉我们，我们可以将其分配给您！

我们有很多项目的标记好第一个问题，并帮助想如果有人想帮助的项目应该是（相对）容易下手🙂

对于错误修正，您只需打开一个 PR。 如果这是一个主要的新功能，那么我们也有一些流程来首先审查该问题，以确保该提案非常适合 WinUI。

我完全同意贡献者指南可能会更好并且很难开始 - 我最近经历了尝试遵循它以实现新功能（ RadialGradientBrush ）的练习，并发现它可以使用很多改进 - 现在在我的待办事项列表以改进指南。

我举个例子。 #1555 和 #1849 似乎是核心控件 (TextBox) 的主要问题，它们在多任务处理时阻止了文本输入和选择。
它们在我应该解决的重要问题列表中名列前茅，但我不知道从哪里开始。 我也不知道我想要/需要逐步调试的代码是否可用。

那些仍然需要由我们的开发所有者分类（分类）（因此有“需求分类”标签 - 我目前正在跟进为什么他们还没有，抱歉）但我希望因为 TextBox 不在WinUI 2 那些将不得不等待 WinUI3。

一旦他们被分类，他们应该应用需要 winui-3标签，这表明他们必须等待 WinUI 3 才能解决他们。

一旦 WinUI 3 开源，那么任何人都可以帮助解决这些问题。

不喜欢使用 C++/WinRT，当然也没有资格接触我所见过的代码库。 如果控件是由 C# 管理的，您将有更多的贡献。

我们知道 C++ 是比 C# 更高的障碍，但计划是 WinUI 将仍然是 C++ 平台。

另一个值得参与的伟大项目是Windows Community Toolkit ，它更容易参与，因为它是 C# 并且有一些宽松的要求。

我们与维护者合作，并经常使用社区工具包来孵化最终迁移到 Xaml 平台的新控件（这确实涉及用 C++ 重新实现）。

WinUI 是否需要 C++/CX？ 如果是这样，这似乎是 Win32 和其他未来目标的问题？

WinUI 3.0渲染层是怎么做的？ 是直接利用D3D11、D2D、抽象层还是什么？ 它是否具有软件渲染层或为此使用 D3D WARP？

WinUI Xaml 框架的渲染主要在Windows 10 组合引擎上实现。 组合层 API 也将成为 WinUI 3 的一部分。

最后，这通常意味着使用 Direct3D、Direct2D 和 DirectWrite 的硬件加速渲染，在某些情况下使用软件渲染有意义。

您还可以使用互操作 API 包含您自己的自定义呈现的 DirectX 内容。

WinUI 是否需要 C++/CX？ 如果是这样，这似乎是 Win32 和其他未来目标的问题？

不 - WinUI 平台是用 C++ 编写的，但您的应用程序绝对不必是！

现在借助 WinUI 2，您可以使用 .NET（C#、VB.NET）或 C++ 创建 UWP 应用程序。

借助 WinUI 3，我们的目标是您将能够使用即将推出的 .NET 5 或 C++ 创建使用 UWP 和/或 win32 API 的应用程序。

@jesbis我认为您可能有点误解了我的问题意图。

1) 我知道 WinUI 是用 C++ 编写的，但是是否有任何 WinUI 代码只需要 Windows VC++/CX 扩展？ 如果它确实需要 CX 扩展，我认为如果 WinUI 想要扩展到其他平台，这可能会导致可移植性问题。 例如，这可能会使 UNO 团队难以采用代码。

2）关于渲染系统。 这里有几件事。

2.a) “视觉层”是否是一个抽象 API，它是否离 DirectX API 足够远，以便它以后可以支持 Vulkan 后端？ （我确定这个问题会在源发布时得到回答，但我只是想知道）

2.b) 我关于软件光栅化的问题更接近于：WinUI 3.0 是否支持完整的软件渲染（不仅仅是文本渲染或其他什么）？ 有时屏幕共享软件在 GPU 加速应用程序（至少在 D3D9 / WPF 中）存在问题，并且在这些情况下强制软件渲染修复了该问题。 或者，如果应用程序在没有硬件 GPU 的 VM 中运行。

安装和试用 vsix 的 WinUI 3.0 Alpha 说明如下：
https://aka.ms/winui/alpha

用Edge New做到了下载链接doenst出现，用chrome-download重复它

用Edge New做到了下载链接doenst出现，用chrome-download重复它

@hannespreishuber下载链接应该在调查的最后一页。 您的意思是该调查在 Chromium Edge 中不起作用但在 Chrome 中起作用吗？

下载链接应位于调查的最后一页。 您的意思是该调查在 Chromium Edge 中不起作用但在 Chrome 中起作用吗？

对两者都进行了调查 - 但最后一页是不同的，也许是我的错。

对两者都进行了调查 - 但最后一页是不同的，也许是我的错。

好的，谢谢 - 我们在两个版本的 Edge 上测试了调查，它似乎有效，所以如果有人在下载时遇到问题，请告诉我们，如果页面内容呈现与 Chrome 不同（设置 > 帮助和反馈 > 发送反馈）🙂

我知道 WinUI 是用 C++ 编写的，但是是否有任何 WinUI 代码只需要 Windows VC++/CX 扩展？ 如果它确实需要 CX 扩展，我认为这可能会导致可移植性问题

@zezba9000我们已经使用标准 C++17 的 C++/WinRT 实现了 WinUI 2 控件和功能（当前在 repo 中的新代码），但 WinUI 3 的其余部分是一个更大和更旧的代码库，目前仍将依赖关于WRL等。我们目前不关注可移植性，但愿意在未来讨论它。

“视觉层”是一个抽象 API，它与 DirectX API 的距离足够远，以便它以后可以支持 Vulkan 后端吗？ （我确定这个问题会在源发布时得到回答，但我只是想知道）

我们目前也不关注视觉层的可移植性。 Visual 层和 DirectX API 之间存在一些松散耦合（不包括实现），但大部分是抽象的。 另外，澄清一下开源：我们开源代码和日常开发流程的最初目标是 Xaml 框架，目前不包括开源可视层。

我关于软件光栅化的问题更多地是：WinUI 3.0 是否支持完整的软件渲染（不仅仅是文本渲染或其他什么）？ 有时屏幕共享软件在 GPU 加速应用程序（至少在 D3D9 / WPF 中）存在问题，并且在这些情况下强制软件渲染修复了该问题。 或者，如果应用程序在没有硬件 GPU 的 VM 中运行。

是的，通过屏幕共享、在虚拟机等中渲染应该都可以工作。 对于大多数内容，应该没有明显的差异。 如果您查看 repo 中的 WinUI 2 代码，您可能还会看到我们用来查询某些效果是否在运行时支持/“快速”并在某些情况下回退到某些效果的更简单呈现的API 的用法，但应用程序应该在使用默认平台控件和功能时，不必做任何特殊的事情来支持软件渲染。

我完全同意你的看法。 但是您必须了解功能和错误之间的区别。 我担心您只考虑 Microsoft 的资源/人力。 但是，您是否考虑过应用程序开发人员在尝试解决控件中的错误时浪费了无数时间？ 从源头上修复这些问题要高效得多，而且确实有助于对平台/工具的感知。

100% 同意 - 我什至不想回忆我花在解决 UWP/WinRT 错误上的小时数。

杰西，

我主要关心开发企业应用程序。 我目前正在使用 WinUI 3.0 Alpha 来构建概念验证，以演示 Xaml、GPRC、多窗口和真正的多线程如何为业务和业务用户提供更高效的应用程序体验。

为什么？ 因为我们需要替代基于浏览器的/小屏幕应用程序。 关于这个话题，我还有很多话要说，但我要在这里谈一谈。

我希望 WinUI 团队和 Microsoft 真正接受和支持为企业构建桌面应用程序。

Web 应用程序在企业中如此迅速地被采用有 3 个主要原因 - 跨平台支持、安全性和易于部署 要成为可行的替代方案，桌面应用程序需要回答这些问题。

似乎大多数软件开发行业都专注于为浏览器和/或移动/平板电脑外形因素提供应用程序。

与“移动优先”应用程序相比，企业应用程序在具有大量 CPU、屏幕大小、内存、存储、图形和带宽的工作站上运行。 这些 LOB 应用程序的用户一次可能会参与几个小时。 我们需要应用程序设计指南来解决这些因素。

企业应用程序中还有其他方面没有得到太多讨论——寿命和技能组合。 再说一次，这里有很多话要说，但我要总结一下。 企业投资构建应用程序，并计划“长期”使用这些应用程序。 这意味着底层技术需要几十年的支持。 我希望 WinUI 成为替代 Win32/MFC 和 WinForms 的下一个长期存在的技术。

IT 部门一直在努力寻找具有合适技能的 SE。 网络技术使这更具挑战性。 我希望看到一个新的堆栈 C#、Xaml 和 SQL (C#XS)，它确定了对构建桌面应用程序的关注。

关于造型，我还想提出一个小问题。 WinUI 企业应用程序应该需要最少的“开箱即用”样式才能正常运行。 此外，这可能直接针对 Fluent，但不要隐藏控件（如滚动条）。 商业用户有大量的屏幕真实状态，如果他们不知道页面上还有更多内容，他们就不会关心 UI 有多“华丽”。

我们需要一个健壮（免费）的数据网格控件。 怎么强调都不过分。

如果您有兴趣，我有更多想法可以分享，但我会在这里停下来总结一下：

• Microsoft 需要提供全面的桌面应用程序开发解决方案。
• WinUI/Fluent 需要满足业务用户的需求，例如功能/表单、桌面用户体验、演示多个窗口的代码示例/项目模板、真正的多线程、数据验证、“类表单”页面。
• Microsoft 需要明确表示他们正在提供 WinUI 来构建高效、长寿命的业务 LOB 应用程序。 另外，为什么 .Net 5 + WinUI 不会是另一个 DLL 地狱。
• 明确WinUI 是Win32/MFC 和WinForms 的替代品。
• 推动 C#XS 作为 IT 技能组合。
•（免费）数据网格

希望你觉得这有帮助。

@robloo轻松休息 - 无需辩论！ 🙂 我承诺在我早期的评论中修复这个失误，这仍然适用。 我想我之前通过继续概括也犯了一个错误。 让我们谈谈您列出的错误。 两个是在我们这里的主要假期之前提交的（我不能代表@teaP ，但我 12 月的大部分时间都处于离线状态）并且我们在工程方面进行了管理变更（恭喜 @ranjeshj！）。 这不是借口，我很抱歉在这些更改和缺席期间没有更快地解决这两个错误。 此处列出的其他内容均已在过去 10 天或更短的时间内提交。

特别指出 NumberBox 是罪魁祸首，而这些堆积有助于我们对时间进行战略性分析，因此感谢您帮助我们看到这一点。 我已安排在下周初与我们的NumberBox开发人员任命的）工程经理NumberBox错误列表，以便我们能够尽快共同解决它们。

@SavoySchuler谢谢！

@SavoySchuler ，您似乎陷入了难以抉择的困境：

a) 修复WinUI 2.x中的bug，延迟WinUI 3.0的发布
或者
b) 将 WinUI 2.x 留给社区，并将内部资源用于 WinUI 3.0，以实现最早发布日期

我猜很多现有的 WinUI 2.x 用户会希望你首先修复这些错误，因为它们目前受到影响，但也许这可以通过提供一个实际的 WinUI 3.0 何时可用的预期来缓解，如果有足够的资源（并假设 WinUI 3.0 将提供超过 2.x 的额外修复）。

就我个人而言，我不希望看到 WinUI 3.0 的发布延迟，并且认为社区参与解决 WinUI 2.x 中的任何关键问题是合理的（毕竟，它是开源的）。 有些人期望因为这是微软的项目，所以他们应该做所有的工作。 不幸的是，这并不现实，其他开源项目也不是这样。

@jesbis ，听到关于 WinUI 3.0 的视觉层很有趣。 您是说对于初始版本，WinUI 3.0 将依赖于Windows.UI.Composition类吗？ 在提取到 WinUI 3.0 之前，是否有可能将更多功能添加到操作系统中以支持视觉层？

作为参考，我感兴趣的事情：

• Win32“AppContainer”模型。 我们在其他操作系统上完全兼容沙箱，但我们希望访问“现代”API
• 视觉层（ Windows|Microsoft.UI.Composition ）
• 视觉层中的DXGI交换链/SwapChainPanel
• 窗口管理 API（AppWindow 等）

@infoequipt感谢您的深入笔记！ 绝对有帮助。 @marb2000可见性

听到关于 WinUI 3.0 的视觉层很有趣。 您是说对于初始版本，WinUI 3.0 将依赖于 Windows.UI.Composition 类？

@MarkIngramUK不，抱歉有任何混淆 - 我之前的观点只是关于开源。

Microsoft.UI.Composition 将成为 WinUI 3 的一部分，Microsoft.UI.Xaml 将依赖于它。 WinUI 3 Alpha 已经是这种情况。

我们正在努力开源 Xaml，这意味着 Xaml 框架代码将存在于这个存储库中，我们的工程团队将在 GitHub 上完成我们所有的日常 Xaml 工作。 但是，Xaml 所依赖的 Microsoft.UI.Composition 包仍将在内部开发，并且仅以二进制形式更新。

感谢@jesbis的澄清，非常感谢。 您将为此使用哪些分发方法？ 我们是一个跨平台的应用程序，所以使用 CMake，并且依赖于 Windows.UI.Composition，所以会喜欢一种轻松引入新的 dll、lib、头文件等的方法。

从操作系统中提取视觉层是否有任何性能影响？ 即，如果您只依赖于 Visual Layer，那么更新到新库是否会有不利影响？

是否有最终开源 Microsoft.UI.Composition 的计划？

@MarkIngramUK我基本上同意你所说的，以及@SavoySchuler在“大局”观点中所说的。 不过，正如您所指出的，我们 WinUI 2.0 用户更难接受错误，因为我们现在有生产应用程序。 我们需要在修复一些不会延迟 WinUI 3.0 的错误和保持 WinUI 3.0 正常运行之间找到折衷方案。 令人沮丧的是，NumberBox 是一个全新的控件，但它似乎立即被忽视了——有人评论说微软在一年多的时间里都不会再使用它。 无论如何，我当然同意 WinUI 3.0 是优先事项，并且不希望它在任何重大方面被延迟。

我可能应该说，我非常感谢 Microsoft 在这里所做的所有工作，以及他们为使方向更加透明和沟通而做出的努力。

您将为此使用哪些分发方法？ 我们是一个跨平台的应用程序，所以使用 CMake，并且依赖于 Windows.UI.Composition，所以会喜欢一种轻松引入新的 dll、lib、头文件等的方法。

@MarkIngramUK会使用 NuGet 包吗？ 即我们正在用WinUI 2.x和 WinUI 3 Alpha 做什么。 我们仍在与 Visual Studio 团队一起制定一些分发细节。 现在，WinUI 3 Alpha 将 Xaml 和 Composition 二进制文件包含在 1 个包中，但我们会将它们分开以支持开源 Xaml 并能够单独构建 Xaml。

从操作系统中提取视觉层是否有任何性能影响？ 即，如果您只依赖于 Visual Layer，那么更新到新库是否会有不利影响？

请继续关注 🙂 Perf 基准测试和工作在我们今年晚些时候的路线图上，所以现在有任何数字还为时过早。

是否有最终开源 Microsoft.UI.Composition 的计划？

它在我们的积压工作中可能会考虑，但我们没有计划。

@MarkIngramUK如果我可以问：您希望从开源中获得什么好处？

组合和渲染代码可能会变得有点深奥，所以我很好奇人们是否真的有兴趣贡献或用作参考。

因为我们现在有生产应用程序，所以我们 WinUI 2.0 用户更难接受错误。 我们需要在修复一些不会延迟 WinUI 3.0 的错误和保持 WinUI 3.0 正常运行之间找到折衷方案。 令人沮丧的是，NumberBox 是一个全新的控件，但它似乎立即被忽视了——有人评论说微软在一年多的时间里都不会再使用它。 无论如何，我当然同意 WinUI 3.0 是优先事项，并且不希望它在任何重大方面被延迟。
我可能应该说，我非常感谢 Microsoft 在这里所做的所有工作，以及他们为使方向更加透明和沟通而做出的努力。

@robloo谢谢！ 我们真的在努力保持透明，很高兴知道这很有价值🙂

只是重申 Savoy 提到的我们确实有开发人员在开发 WinUI 2.x（希望也可以从 PR 日志中看到）所以我们肯定仍在同时投资 WinUI 2 和 3 - 这只是我们的大部分资源在 WinUI 3 上。我同意 NumberBox 特别需要一些关注，我们的 Xaml 控件开发负责人现在正在研究它。

@robloo你是最棒的！ 😄 再次为混淆感到抱歉 - 唯一提到的大约 1 年的延迟是 NumberBox 的附加输入验证模式，因为它们在我们为 3.0 计划的全部输入验证工作中被阻止。 否则， @ teaP 、 @ranjeshj和我将从下周开始出现在

我认为@jesbis涵盖了其他所有内容！

@杰斯比斯，

@MarkIngramUK会使用 NuGet 包吗？ 即我们正在用WinUI 2.x和 WinUI 3 Alpha 做什么。 我们仍在与 Visual Studio 团队一起制定一些分发细节。 现在，WinUI 3 Alpha 将 Xaml 和 Composition 二进制文件包含在 1 个包中，但我们会将它们分开以支持开源 Xaml 并能够单独构建 Xaml。

老实说，我对 NuGet 不太熟悉，但是看着这个SO 答案，它似乎只有在您使用 CMake 生成 VS 项目文件时才有效，这不是我们通常的工作方式（通常只需打开文件夹，它使用 Ninja 作为生成器）。 很遗憾您不能发送源代码，因为您也可以使用vcpkg 。 作为参考，我们从源代码构建所有库（这避免了任何潜在的 ABI 问题，特别是考虑到我们也在 Windows 上使用 Clang/LLVM 构建）。

是否有最终开源 Microsoft.UI.Composition 的计划？

它在我们的积压工作中可能会考虑，但我们没有计划。

我对此很感兴趣，所以如果/何时发生，我很乐意参与讨论。

@MarkIngramUK如果我可以问：您希望从开源中获得什么好处？

组合和渲染代码可能会变得有点深奥，所以我很好奇人们是否真的有兴趣贡献或用作参考。

最初的想法是贡献/扩展（正如我之前提到的，我们依赖于 Windows.UI.Composition，而不是 Xaml 框架/UWP），尽管大声思考，将可视层移植到 Vulkan 或 Metal 后端以进行跨平台平台可能令人兴奋，但我只考虑了 30 秒。 此外，开源将减轻人们对采用另一种框架的担忧，该框架最终将在几年内被微软放弃（我们当前的应用程序是基于 WPF 构建的，我们以前的应用程序是基于 MFC 构建的，我们有使用 Silverlight 的 Web 组件，所以，你可能会看到我来自哪里......）。

数字框

嗨，大家好！ @teaP 、 @ranjeshj和我今天完成了所有开放的 NumberBox 项目。

• 我们已经关闭了一些。
• @teaP提交了多个PR的组合此处为
• 我们为其余部分决定了一个行动方案（#1721 除外），并将尽快回复修复。 #1721 需要更多的工作来诊断最佳前进路径。 我们将继续努力解决这个问题。

感谢所有与我们合作的人。 🙂 我们❤️ WinUI！

WinUI 社区通话是否有“日历”？ 例如：以公共日历的形式，我们可以将其添加/集成到我们的 live/google/* 日历中，以自动更新通话详细信息。

YouTube 活动会提前安排，因此您可以在“即将到来的直播”下方添加 Google 提醒：

https://www.youtube.com/channel/UCzLbHrU7U3cUDNQWWAqjceA

我们也有一个 .ics 日历邀请，但它给某些人带来了问题，而且没有办法更新它，所以我们现在放弃了。