大家好。
对于那些不认识我的人，自 2008 年以来，我一直是一名资深的、顽固的 XAML 开发人员。我几乎参与了与 XAML 相关的几乎所有事情（包括 WPF、Xamarin Forms 和 UWP 等）和我写这篇文章的唯一原因是帮助并成为大量被遗忘的开发人员的声音，他们已经脱离了循环并跳槽，因为他们对微软在应用程序模型方面做正确的事情失去了希望，尤其是与讨论中的主题相关的 GUI。
在与社区进行了长时间的交谈之后，我自己也参与了Uno Platform和AvaloniaUI等项目，这就是我所拥有的。
在这里，我试图浓缩我在这些对话中收集到的所有意见和观点。 正如您将看到的，他们对 WinUI 看似走的道路非常批评。
被遗忘的开发者保持沉默或被忽略
正如我之前所说，他们已经脱离了循环，或者只是筋疲力尽。 他们中的一些人多年来一直试图引起你的注意，但被忽视或沉默了。
作为总结，被遗忘的开发者：
- 通常拒绝在浏览器上运行或基于 HTML+JS 的任何内容
- 辞职后切换到其他平台/框架，因为他们没有更好的网络/移动选择。
- 他们厌倦了看到微软一直未能提供允许所谓的“一次编写，到处运行”的 GUI 框架。
- 他们不希望对 WPF/UWP 进行轻微的进化升级
需要考虑的关键点
- 认识到 WPF 的重要性。 14 年前，它以一种全新的方式改变了我们设计 GUI 的方式。 它的力量是前所未有的。 很多很多开发人员仍在将其他基于 XAML 的表示技术与 WPF 进行比较。 它提供的自由级别（您可以使用 WPF 做任何事情）使开发人员不愿意使用其他 XAML 框架，尤其是那些不开发移动/Web 应用程序的人。
- 通用 Windows 平台 (UWP) 想充分利用 WPF，但为时已晚。 它花了数年时间才提供类似的功能。 在某些方面，它比 WPF 更好，但仍然有一些主要缺点：
- 它不是通用的。 Windows 10 Mobile 的消亡，这是另一个值得分析的有趣主题，将One Windows 的愿景缩减到最低限度。
- 沙盒限制使 UWP 不适用于高级应用程序。
- 分发渠道是 Microsoft Store，它已被证明不适用于各种应用程序。 认证过程本身既痛苦又缓慢。 至少可以说，为 .NET Native 编译应用程序很麻烦。
- 明显缺乏第三方控制。 值得注意的例子：DataGrid 和 Charts 等
- 像 Xamarin Forms 这样的框架在错误的方向上分歧太大了。
具体来说， Xamarin Forms 已经变成了一个内婚生态系统，它只提供跨平台需求的即时短期满足。 它变成了一大堆补丁，以克服其“最高公分母”方法的固有限制。 此外，Xamarin Forms只是iOS 和 Android 的同义词。
这不是咆哮，而是悲哀的现实。
那么，我的提议是什么？
充分利用 WPF 和 UWP：
- 一套成熟的标准控件，足够丰富，几乎可以满足开发人员的所有需求，包括DataGrids 和 Charts。
- 标记扩展
- 自适应触发器
- 数据模板
- 绑定
- 具有值强制的依赖属性
- 风格
- 对验证的控制支持
- MVVM 就绪
并使其跨平台！
- 支持 Windows、Linux、Mac、iOS、Android 和 WebAssembly
WinUI 不应该重复 WPF 和 UWP 的错误
应该采取什么行动？
- 不要将 WinUI 与 DirectX 耦合
- 跨平台思考：每个平台都有能够绘制加速图形的图形引擎。 Windows 可能是参考平台，但其他操作系统应该将 WinUI 视为创建 GUI 的最佳方式。
- AvaloniaUI已经是跨平台的。 为什么不向项目中的人寻求帮助和反馈来改进 WinUI？
SuperJMN
所有59条评论
我认为 Xamarin 将合并到 .NET 5；
如果他们采用 UWP XAML 作为标准并从那里开始工作，Microsoft 和 UNO 将使其成为桌面、移动、Web 浏览器 (Azure) 和物联网的最佳选择，那就太好了。
他们可以称之为
UWP vNext（基于 WinUI）/ Silverlight 6 (UNO)
我认为 Blazor 的努力是将 .NET 正式引入 WebBrowser 的第一步，使用其当前的默认呈现，即。 HTML DOM
但我相信很快他们甚至可以提供另一个渲染引擎，WinUI 的轻量级补充，围绕 Silverlight、UNO 平台和 Xamarin 运行的东西......比如 Flutter / WPF
TonyHenrique
于 2020-02-25
如果他们采用 UWP XAML 作为标准并从那里开始工作，那就太好了
你们想要的一切都已经在 Uno 发生了。 MS 明智的做法是买断这些人，然后雇佣他们来指导 Uno 的最终发展。
sharpninja
于 2020-02-25
这可能是请求此类功能的错误位置。 尽管我很想同意这个请求中的所有内容，但我相信 WinUI 团队和 Windows 社区的许多高级开发人员认为 WinUI 的定义非常狭窄。
在理想的世界中，WinUI 就像 Material Design。 将有办法在具有实现它的各种库的任何平台上使用它。 但是，WinUI 不是设计语言，Fluent Design 也不是。 微软不在模型领域，使得他们的 UI 产品远远落后于竞争对手。
WinUI 是一个用于 Windows 应用程序的 UI 库，这很清楚。 设计语言与实现并不分离，并且实现是平台专有的，因为组合等功能严重依赖于平台依赖性。 从移动/跨平台开发人员的角度来看，这很糟糕，但这里的努力确实是针对 Windows 应用程序的。
这也是为什么 Uno Platform 可能永远无法真正成为 WinUI 的原因，除非他们将 DX 11 移植到每个平台。
我建议您研究 Comet（基于 .Net 的跨平台开发框架）。 它还处于早期阶段，但这个概念与 Flutter 并无不同。 它也使用 Skia（作为一个选项）以可组合/声明式 UI 模式绘制 UI，因此开发人员可以实现 UI 库，如 Material Design，并使其在每个平台上看起来完全一样。
nerocui
于 2020-02-25
不，它不应该是跨平台的。 它被称为 Windows UI 是有原因的。 让我们从一个可以跨所有 Windows（平台和语言）工作的 UI 系统开始，嘿？ 这甚至还没有实现。 我们仍然在 .net 框架、.net core、uwp 和 C++ 故事之间进行划分，它至少有 uwp，但没有游戏开发者使用它，因为 UWP/WinRT 仍然存在一些问题 - 分发、强制任务栏和标题栏弹出全屏时（哎呀）。
考虑跨平台将是对资源的巨大浪费。 请先在 Windows 上正确安装。 并获得 .net 5，修复 UWP 和窗口故事，并将 DirectX 放到 C# 上。 并修复GC。 在狭窄的场景中还有很多事情要做，只是在 Windows 上。
和OP。
UWP 是通用的。 说它不通用是一个错误的说法（他们从来没有打算针对 Android，感谢上帝）。 最初的承诺已经兑现。 所有 Windows 设备都运行 UWP。 Windows Mobile 是一个独立的操作系统，他们必须摆脱它。 所有新的 Windows 平台都将是 Windows（10 或 10X）。 我想最终基于CoreOS。 它们都将运行 Windows 应用程序。 只是因为我们目前没有 Windows 手机是偶然的。 我们拥有所有其他设备类型。 我们很快就会有 Neo 和 Duo。
沙盒限制——这些都是好事。 Win32 风格的系统范围的访问通常应该被淘汰。 如果您有特定要求，您应该提出您的要求，以便我们可以讨论它可以/应该如何在 UWP 容器内完成，以及是否应该允许您按照您建议的方式进行操作。 并确定 UWP 是否需要该功能。 因为我能想到一些可以用 UWP 编写的高级应用程序没有问题。 我可以有程序！ 你需要讨论细节。
.net native 正在被替换，分发故事将随着 .net 5 的变化而改变。我认为可以公平地说微软正在努力解决这个问题。 他们肯定知道这些问题。 但是你应该提出具体的问题来解决这里真正的潜在问题。
“不要将 WinUI 与 DirectX 耦合” - WTF？ 它绝对应该与 DirectX 相结合，即原生 Windows 图形堆栈。 请不要考虑其他任何事情。 我绝对不想在引擎盖下遇到 OpenGL 渲染表面。 这会破坏兼容性并造成各种混乱。
Gavin-Williams
于 2020-02-26
@加文-威廉姆斯
太好了，让我们对 WPF 做一个稍微进化的升级。
UWP 是通用的
“所有 Windows 设备都运行 UWP”意味着没有移动设备。 HoloLens 是小众，Surface Hub 是小众，Windows 10 IoT Core 是个笑话。
它绝对应该与 DirectX 相结合
作为开发人员，硬耦合让我起鸡皮疙瘩。 图形堆栈不能互换的主要原因有哪些？
这就是所谓的“模块化”。 微软一直在为此苦苦挣扎。
沙盒限制是好事
是的，只要它们没有严格限制可以构建的应用程序的范围，它们就是。 您是否尝试过从 UWP 调整分区大小？
SuperJMN
于 2020-02-26
我认为值得一提和提醒的是，谷歌正在开发 Flutter，他们并没有将其称为 GoogleUI 或 AndroidUI。 它适用于任何地方——甚至在网络和桌面上。 我这么说是因为似乎有“让它在 Windows 上运行”的倾向，但如果存在另一个更便宜、更快、更易于使用的竞争产品，并且可以在 Windows + 其他所有东西上运行......开发人员会怎么做（和相应的市场）选择？ 作为一个小企业主，我可以告诉你，考虑到这两种选择，我知道我将投资放在哪里。
Mike-E-angelo
于 2020-02-26
将 DirectX 移植到其他平台似乎是一项艰巨的工作，也许解决方案是使用 OpenGL 或 Vulkan 而不是 DirectX
asierpn
于 2020-02-26
@Gavin-Williams，我不知道您是否熟悉 UWP，但是当您构建/分发时，您的目标是 Windows 的特定版本（或版本范围）。 这个想法是绝对耦合的，也是 UWP 没有像 WPF 那样成为主流的原因之一。
@nerocui UI 语言的全部目的是将 UI 设计与屏幕中的原始绘图分离。 这就是您看到 HTML 能够在 ARM/x64/x64 中呈现的原因。
XAML 提供了 UI 原语/合成/动画的出色抽象，由于开发成本和平台范围，请求绝对有意义。
paulovila
于 2020-02-26
我恭敬地不同意@SuperJMN。 当然，UWP 尚未达到与 WPF 相同的功能。 尽管它作为构建内核级工具的框架存在局限性，但对于几乎所有其他软件开发任务，只要在应用程序清单中指定正确的功能，您就可以从多个角度（安全性、易于部署、安装/卸载）获得更好的用户体验经验等）。 UWP 的安全沙箱是一项重要（基本）功能。 在许多方面，UWP 现在远远领先于 WPF。
UWP .Net 编译器消除了代码混淆的需要以及这可能给 WPF 带来的不稳定性。 随着编译器的改进，性能有望随着时间的推移而提高，而无需更改代码。 UWP 本身在如何利用 DirectX 和其他系统级资源方面具有更好的设计。 在与其他语言（尤其是 C++）集成时，它也比 WPF 具有巨大的优势。 在 UWP 下，将高性能 C++ 组件与 C# 集成是微不足道的。 对 DirectX 表面的访问也得到了很大改善。
UWP 中剩余的孔可以很容易地堵塞。 我认为更大的问题是微软未能达到与 WPF 相关的质量水平。 WPF刚刚工作。 Microsoft 也未能认识到 LOB 要求的至关重要性，例如数据网格、INotifyDataErrorInfo、具有验证状态的控件以及开箱即用的健壮数据库。 其中大部分已经解决，但时间太长了。 仍然缺少非矩形区域。
另一个严重的失败在于某些选择远离 UWP 的 WPF 开发人员。 采用对于建立势头至关重要。 然而，考虑到微软在其举措上多次摇摆不定，采用传奇是可以理解的。 很明显，微软又在胡说八道了。 通过允许 WPF 插入 UWP UI 服务来复活 WPF 表面上看起来很酷，但它确实分散了使 UWP 稳固的注意力。
我完全同意@SuperJMN 的说法，即开发人员对微软会做正确的事情失去了希望。 正确的事情确实会有所不同，具体取决于您正在构建的软件类型。 如果是高性能 LOB 应用程序，需要快速创建并展示广泛的功能，同时又安全且易于安装，那么 UWP 大部分都在那里，除了质量方面。 这种质量差距是最能扼杀 UWP 的原因。
HTML+JS 是当今的跨平台解决方案。 我们不需要重新发明它。 如果目的是使 XAML 更具可移植性，那么在 IOS 和 Android 上使用高性能 XAML 渲染引擎会更有意义。
Noemata
于 2020-02-26
我非常同意 WinUI 未来应该以跨平台为目标。 这里有一些进一步的想法。
紧迫的优先事项
我同意一些评论，即当务之急是确保 WinUI 3 在具有 .Net 5 集成的 Windows 上运行并且错误已得到修复。 但是，如果现在还为时不晚，那么在做出架构决策时，应该考虑未来跨平台的目标。
为什么 WinUI 应该是跨平台的
有明显和最重要的原因 - 开发人员希望在不重写代码等的情况下瞄准尽可能多的受众，而 C#（或我想是 C++）/XAML 是一个很好的组合。 如果没有跨平台的故事，他们将转向 Flutter 等其他技术。
另一个原因是确保 WinUI 继续得到 Microsoft 的支持。 微软只有在他们自己的应用程序使用 WinUI 时才可能继续支持它。 他们越来越专注于让自己的应用程序跨平台。 诚然，一些跨平台框架如 React Native 和 Xamarin 会在底层使用 WinUI，但如果 Flutter 或基于浏览器的渲染等其他框架胜出怎么办？ 然后 WinUI 将变得多余，并像 WPF 一样进入维护模式。
跨平台应该如何实现
尽管 Uno 是一个很棒的项目，但在我看来，让渲染（和输入）层跨平台并在此基础上构建更有意义，这正是 Flutter 和 AvaloniaUI 所做的，而不是包装原生控件。 使渲染层和输入层跨平台的方法有几个优点。 在我看来，渲染层和输入层的 API 表面小于控件的 API 表面（但我想这取决于您是否在一些基本控件之上构建控件等）。 其次，如果您依赖包装原生控件，那么您将受到平台的摆布。 如果他们更改了他们的 API，您必须更改您的 API 或实施变通方法。 如果您在弃用时没有足够快地执行此操作，您的框架将会崩溃。 如果您想向控件添加新功能，您可能必须为每个平台实现它。 您无法真正对希望框架如何发展有“愿景”，因为您与平台框架相关联。 此外，由于控件的外观和行为不同，它还要求开发人员始终在每个平台上进行测试。 此外，实现更强大的功能（如组合层）将是困难的/不可能的。 使渲染层跨平台解决了所有这些问题，如果您希望在每个平台上具有不同的外观，那么您可以添加不同的样式。 （我承认，某些行为在不同平台上会保持不同，例如在 Mac 上滚动！）。
由于 WinUI 目前正在将控件、渲染和输入层与平台分离，因此它似乎处于一个独特的有利位置。
抽象渲染层的一种方法是使用 Skia。 但是，我不希望通过强制这种抽象来影响性能。 我有另一个建议来抽象渲染层，这是针对 2D 图形的 C++ 提议 - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0267r9.pdf . 他们显然在 API 表面上做了很多工作，而且看起来相当全面。 他们认为 2D 图形的“问题”在很多年前就已基本解决，我必须同意他们的观点，即他们的 API 表面看起来相当完整。 有很多人反对这个提议，但即使它没有被接受，我认为 API 表面也可以使用。 如果您为此 API 表面编写 Direct2D 后端，那么如果提案被接受，它将使 MSVC 团队不必编写它。 也许 WinUI 团队可以以此为理由，允许其工作或添加一些额外的团队成员。 此外，也许该论文的作者愿意提供帮助。 您可以使用 Skia 或其他工具为其他平台编写后端，如果提案最终被接受，则在完成时切换到本机实现。
最后，展望未来，我想提一下 WASI - https://wasi.dev/ 。 这似乎目前专注于系统编程，但它可能有可能变成一个成熟的跨平台应用程序框架（它内置了跨平台和安全性），上面的 C++ 提案可能为渲染层 API。 （虽然这可能很遥远）。
benstevens48
于 2020-02-26
从证据来看，考虑到他们存储库的内容，像@SuperJMN这样的人有很多可信度。 我可以看到@SuperJMN可能在 UWP 还在成熟时就放弃了（可以理解）。 微软会很好地审查这里评论的人的存储库。 根据他们向世界展示的工作主体，一些声音并不是特别可信。
Noemata
于 2020-02-26
@Noemata我曾经是 XAML+MVVM 的忠实粉丝。 我曾在 Silverlight、WPF、WindowsPhone、Metro(WinRT) 中使用过它。 当谈到 UWP 和 Xamarin 时，我筋疲力尽......
很难看出这次迭代与我查看新 XAML 堆栈的所有其他时间有何不同。
ipjohnson
于 2020-02-26
微软推出了一些很棒的 UWP 示例应用程序。 他们确实很好地展示了可能性。
这是部分列表：
https://github.com/Microsoft/Windows-appsample-customers-orders-database
https://github.com/microsoft/InventorySample
https://github.com/microsoft/VanArsdel
https://github.com/microsoft/BuildCast
https://github.com/microsoft/Windows-appsample-shopping
还有很多很好的例子。 没有一个以易于重新调整用途或结构化的方式构建，因此样本与其他作品具有凝聚力。
我不记得使用相应的 WPF 示例付出了多少努力。 这大多是好的。
问题？ 使用 UWP 和 XAML 花了很长时间才到达我们现在的位置。 而现在，信息又一次混乱了。 如果微软在 UWP 首次发布时仅仅提供了体面的 Visual Studio 项目模板，我们对 UWP 的负面情绪就会减少。 对于最好的 VS 模板，你必须去这里：
https://github.com/microsoft/windowsTemplateStudio
尽管是一套非常灵活和完整的 UWP 应用程序构建块，但并非完全开箱即用。 你如何找到这一切？ 没有线索。 去寻宝做你的工作并不能建立信心。 拒绝采用 WinRT 的 Office 团队没有帮助。 无论他们的理论臂长范围如何，他们都会驱动许多进入操作系统的内容。 抛开质量问题、错误、Windows Phone 故障以及不一致的投资和消息传递，我们就在这里。
Noemata
于 2020-02-26
微软推出了一些很棒的 UWP 示例应用程序。 他们确实很好地展示了可能性。
@Noemata我同意，它们真的很酷的样本。 但是使用 UWP 开发复杂的应用程序是疯狂的。 这当然是可能的，但要困难得多。 是的，我确实怀念 WPF 的“它只是工作”的时代。
MS 应该作为示例提供的第一件事是一个简单的 UWP 应用程序，您可以将其发布到 MS 商店之外（是的，它并不像您想象的那么容易）
另一件让我感到不舒服的事情是，UWP 被认为是“移动优先”，放弃了正确的桌面体验。
如果我错了，请纠正我，但大多数开发人员使用 UWP 开发桌面应用程序，并且 UI 与此不匹配。 首先想到的是滚动条——它从一开始就针对触摸板进行了优化。 但是对于桌面用户来说，滚动体验非常糟糕（旁注：我认为 WinUI 团队正在努力解决这个问题）。 我已经在 Google 上搜索了很多东西，以找到一个可以让滚动条再次“正常”的解决方案——这简直太疯狂了，我不能只调用一个 API 函数来做到这一点。
同样，单选按钮/组合框的最小尺寸也针对移动设备进行了优化。 简单地设置单选按钮的宽度会被忽略，您实际上需要设置“MinWidth=0”才能将其考虑在内。
文本按钮的颜色是白色的，然后是黑色的焦点——这是怎么回事？ 并且文本按钮有一个“x”，您可以使用它来清除它 - 那是触摸板 - 为什么没有触摸板时我会有它？
默认文本框已启用拼写——我为什么要这样？
还有其他问题，但我已经解决了这些问题。 但最大的问题是，本来应该需要10分钟的事情，通常需要2个小时甚至更多。 我简直失去了估计的能力——每当我说某事需要我半天的时间，我就需要2-3天。
jtorjo
于 2020-02-27
大家好，
因为这是一个一般性讨论问题，我不知道在哪里可以放置我的 UWP 愿望/功能请求.....我借此机会在这个线程中：
- 更好地支持将uwp 应用程序集成到 Windows 资源管理器的上下文菜单中
- UWP 标记扩展缺少
IServiceProvider以及使用标记扩展的元素本身 - UWP样式触发器丢失
- UWP 隐式数据模板问题。 参见例如here
- 没有用户交互就无法进行自动打印（仅适用于 POS）请参见此处
以上所有功能或问题都已在 uservoice 上得到解决，现在已被放弃。 有人知道这些问题发生了什么吗？ 我们应该在反馈中心上重新创建它们吗？
mfe-
于 2020-02-27
喜欢“被遗忘的开发者”这句话。 我认识很多才华横溢、经验丰富、对技术充满热情的人。 他们是资深的 .Net 开发人员。 我毫不怀疑，总的来说，他们可以比许多在 iOS 和 Android 应用程序开发中茁壮成长的孩子制作更好的应用程序。
如果 WinUI 能够为他们提供一条愉快而稳健的途径，让他们利用他们在 C# + .Net + Xaml 方面的丰富经验来制作适用于 Windows、Android、iOS 和 Web 的应用程序，那么许多人将会跳上马车，世界将从他们的高-优质的应用程序。
WinUI + Uno 平台可能是最终的选择。
zipswich
于 2020-02-27
UWP 标记扩展缺少 IServiceProvider，以及使用标记扩展的元素本身
让你在这里@mfe-！
Mike-E-angelo
于 2020-02-27
让你在这里@mfe-！
@Mike-EE 哇，太棒了！ 我记得当我想将 CalcBinding 移植到 UWP 时遇到了这个问题。 我最终做的是一种解决方法，我在视图模型中添加只读字段。
jtorjo
于 2020-02-27
“一次编写，到处运行”。
微软不久前就放弃了这一点。
jdrch
于 2020-02-28
Mike-E-angelo
于 2020-02-28
被遗忘的开发者保持沉默或被忽略
喜欢“被遗忘的开发者”这句话。
让我们以这个名字组织起来吧！ 💪
Beelzenef
于 2020-02-28
我只希望有一个由微软开发和支持的跨平台 UI 框架。 .NET 生态系统除了 _Uno Platform_ 和 _Xamarin.Forms_ （如果他们仍在针对桌面工作的话）之外没有任何东西。
即使我决定从头开始编写一个仅限 Windows 的业务应用程序，我也不相信微软完全致力于 UWP。 如果我错了，请纠正我，但他们没有放弃 Office UWP 应用程序转而支持 Office Online PWA 吗？ 如果 MS 放弃了自己的第一方框架，那么我为什么要信任 UWP？ _咳嗽银光_
值得庆幸的是，WPF 还没有被放弃。 但这只会增加我的怀疑。
sungaila
于 2020-02-28
AlperOZCAN
于 2020-02-28
对于那些寻求跨平台解决方案来开发应用程序的人来说，Unity 是您的不二之选：
与所有此类解决方案一样，您最终会得到一个包含迷你操作系统的框架。 Java 是巧妙地伪装成一种编程语言的操作系统。
现代浏览器现在是一个迷你操作系统。 我认为我们有足够的这些。 WinUI/UWP 应该是 Windows 10 及更高版本的本机 UI。 拥有一个在更多地方运行的 XAML 引擎可能是有意义的。 我不相信这会违背 Unity 之类的逆风。 在微软开始重新发明 Silverlight 之前，我宁愿看到一个精致、高质量的 UWP，这样我们就可以在其他平台上托管 XAML。 我们都知道效果如何。 如果您还没有看过 Unity，那么您就错过了。 也就是说，准备好进行大量编码甚至更多的调试。
下周我将发布一组用于 UWP 的 VS 模板，让您在几秒钟内创建应用程序。 这已用于“内部”项目。 如果只有 VS 内置了正确的构建块，这将证明 UWP 可以成为开箱即用的 RAD 框架。
Noemata
于 2020-02-28
下周我将发布一组用于 UWP 的 VS 模板，让您在几秒钟内创建应用程序。 这已用于“内部”项目。 如果只有 VS 内置了正确的构建块，这将证明 UWP 可以成为开箱即用的 RAD 框架。
@Noemata听起来很酷！ 我很好奇！
jtorjo
于 2020-02-28
如果你们都想要一个基于 .Net 的、可以适应任何设计语言的跨平台 UI 框架。 别再看了，彗星就是它。
https://github.com/Clancey/Comet
如果您有一些空闲时间，请参与贡献，因为它仍处于早期阶段。
Comet 基本上以现有的所有平台为目标，它使您可以选择在每个平台中定位本机控件或使用 Skia 绘制所有内容，以便它们都保持一致（Flutter 是如何做到的）。
它使用声明式 UI 和 MVU 模式。 它由 Microsoft 的首席项目经理架构师 James Clancey 开发。 虽然它还没有得到官方支持，但有足够的社区牵引力，它可以。
在 Comet 中，UI 只是一个库，因此您（或者微软可以）可以开发一个 WinUI 库，就像 Comet 拥有一个 Material Design 库一样。
nerocui
于 2020-02-28
如果你们都想要一个基于 .Net 的、可以适应任何设计语言的跨平台 UI 框架。 别再看了，彗星就是它。
@nerocui这听起来很酷，但至少从外观上看，没有 XAML 设计器。 在当前阶段构建复杂的 UI 可能是疯狂的。 但它看起来很有希望。
jtorjo
于 2020-02-29
如果你们都想要一个基于 .Net 的、可以适应任何设计语言的跨平台 UI 框架。 别再看了，彗星就是它。
@nerocui这听起来很酷，但至少从外观上看，没有 XAML 设计器。 在当前阶段构建复杂的 UI 可能是疯狂的。 但它看起来很有希望。
这与拖放无关，而是在对代码进行更改时在设计器中实时预览 UI。
sharpninja
于 2020-02-29
下周我将发布一组用于 UWP 的 VS 模板，让您在几秒钟内创建应用程序。 这已用于“内部”项目。 如果只有 VS 内置了正确的构建块，这将证明 UWP 可以成为开箱即用的 RAD 框架。
这是使用 NoesisGUI 吗？ 如果是这样，那么 LOB 应用程序就会缺少很多功能。 现在，针对 Unity 的 WinUI 会很棒。
sharpninja
于 2020-02-29
我创建了一个存储库来记录 XAML 的当前状态，希望人们能够提供帮助并提供见解和实际代码片段，其中列出了如何以各种 XAML 风格完成任务。
sharpninja
于 2020-02-29
简单的问题，超越当今的沙盒，拥抱跨平台所需的东西。 已经为 Windows/OS 的所有其他方面做这件事了，为什么不做 UI。
anthonyadame
于 2020-03-01
采取沙盒跨平台。
来自：anthonyadame [email protected]
发送：2020 年 2 月 29 日星期六晚上 8:00:13
致：microsoft/microsoft-ui-xaml [email protected]
抄送：夏普忍者[email protected] ; 评论[email protected]
主题：回复：[microsoft/microsoft-ui-xaml] 讨论：WinUI 应该是跨平台的 (#2024)
简单的问题，超越当今的沙盒，拥抱跨平台所需的东西。 已经为 Windows/OS 的所有其他方面做这件事了，为什么不做 UI。
—
您收到此消息是因为您发表了评论。
回复此电子邮件直接，查看它在GitHub上https://github.com/microsoft/microsoft-ui-xaml/issues/2024?email_source=notifications&email_token=AD3GCLAISGPMJCQ4AYDPDLLRFG6S3A5CNFSM4K3JAUQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENMOWIY#issuecomment-593029923 ，或退订https://github.com/通知/取消订阅授权/AD3GCLDKTTDCWIJ2ED3OKC3RFG6S3ANCNFSM4K3JAUQA 。
sharpninja
于 2020-03-01
在 UWP 下，将高性能 C++ 组件与 C# 集成是微不足道的。 对 DirectX 表面的访问也得到了很大改善。
@Noemata除了我关心的是不必从编写 C++ 开始外，WinDev 一直在尝试使 .NET 语言在 C++ API、托管 Direct X、XNA、.NET 的正确 AOT 编译方面平等相待代码，COM 功能，....
pjmlp
于 2020-03-02
使 WinUI 3.0 跨平台化将是将现有 .NET/Forms 应用程序移植到 WinUI 的论据。
一开始支持 macOS 就足够了，当它没有与 Windows 相同的性能时，或者没有像动画这样的所有功能时也没有问题。
Windows 是参考平台； 当然，它必须与 DirectX 耦合以获得最佳性能。
在我看来，仅仅为了支持 macOS 而尝试用 HTML+JS 重写大型 C# 应用程序是没有意义的。 而且对于新的桌面应用程序，C# 是更好的选择。
对于桌面应用程序，C# 和 XAML 比 HTML+JS 可靠得多。
使 WinUI 3.0 跨平台确保 .NET、C# 和 XAML 的未来。
fn2020
于 2020-03-05
大家好
我是在伦敦工作的 WPF 合同开发人员。 自 2006 年以来，我一直在使用 WPF 为许多金融机构构建复杂的高性能用户界面。以下是我对此的看法：
1) 我密切关注英国的就业市场。 自 2006 年以来，100% 的 WPF 招聘广告（其中有 1000 个）用于为金融部门构建高性能金融交易桌面应用程序。 目前还没有针对任何行业的 UWP 开发人员的招聘广告。
2) 这些桌面交易应用程序无法使用 UWP 或即将推出的 WinUI - 由于许多复杂的原因，与 WPF 相比，它还不够好。 此外，流畅的设计并不是这些用户感兴趣的东西——它只需要看起来像一个 excel 网格——没有动画，没有样式——只有数据和惊人的性能。
3) 这些客户对跨平台解决方案完全不感兴趣。 没有人使用 Mac，移动设备也不是他们感兴趣的东西。
4) 这些 WPF 开发团队在 3rd 方 WPF 控件库上投入了大量资金（时间和金钱），或者通过像我这样的人为他们开发了复杂、高性能的自定义控件套件。 除非有非常显着的好处（在可预见的情况下不会有），否则他们不会离开 WPF
5) 对于这些金融机构，任何不需要为桌面/WPF 明确编写的应用程序都是使用 Web 技术和 Javascript 编写的。 他们对比这更奇特的东西不感兴趣——没有颤动，没有火焰等等。
这就是英国的情况。 数以百计的 WPF 开发人员不希望很快进入任何新的领域。 零 UWP 开发人员（除了可能为商店开发应用程序的少数单人乐队 - 从商店的状态来看这是值得怀疑的）
另外，我不理解所有关于跨平台的歇斯底里。 跨越移动和桌面的跨平台是一项愚蠢的差事。 永远不会有趣。 微软在桌面和手机上运行的 UWP 应用程序上尝试了这一点——这是一场灾难——将应用程序限制在最简单的 UI 上，而这些 UI 不能做任何复杂或有趣的事情。 桌面和移动设备是为不同的任务和用例而构建的，并且需要不同的应用程序——我们都知道这一点。
对我来说，我希望看到我的 Microsoft 在不牺牲向后兼容性的情况下直接对 WPF 进行更多投资。 我希望看到 WPF 在非托管 c++ 中支持控件开发，这样我们就可以更接近金属。 我希望看到更好的绑定技术、更好的数据模板、更好的控制模板功能，包括部分继承。 我希望看到更好的调试工具和可视化树分析器。 我希望看到 XAML 调试更加充实。 我希望 UI 中有更好的多线程支持。 我想要很多很多东西，我的英国 WPF 承包商伙伴也是如此。
当前的 Microsoft 路线图没有给我任何我想要的东西，以及我不关心的所有东西。
如果微软不支持这个愿景（他们现在显然不支持），那么计划 B 将是社区将 WPF 塑造成它需要通过开源贡献的平台——假设微软在允许新的代码和想法成为 WPF 框架的一部分。
deanchalk
于 2020-03-08
@deanchalk我认为大部分内容可能更好地放置在 WPF 存储库中，以向他们展示对 WPF 的兴趣，在这里发布它主要是说您对 WinUI 存储库中所做的事情/本期讨论的内容不感兴趣。 虽然那是有效的输入，但它可能不会导致超出无效讨论的建设性内容。
weltkante
于 2020-03-08
@weltkante @deanchalk回购中有一个问题，要求在 WinUI 中提供“旧版控制支持”：https://github.com/microsoft/microsoft-ui-xaml/issues/1833
至少第 4 点）适合该问题，并且应该很可能在此处重新发布以证明微软投资的理由。
Felix-Dev
于 2020-03-08
@deanchalk ，我仍然是 WPF 的忠实粉丝。 这是一个很棒的工具，谢天谢地，它开始受到微软的喜爱。 微软选择放弃 WPF 的方式是最不幸的。 UWP 是闪亮的新玩具，不应该排除对 WPF 的持续投资。
UWP 在很多方面都是正确的前进方向。 不幸的是，第一次迭代忽略了使用 WPF 并可能考虑迁移的人们的一些最关键的要求。 其中最重要的是 XAML 碎片在单个组织内部的相当惊人的状态。 WPF ！= Silverlight ！= UWP ！= Xamarin。 哇！
对于选择在 2020 年巩固自己在 WPF 中的 WPF 开发人员，我不太同情。事情已经发生了很大的变化。 能够使用 WinRT API 的 XAML Islands 为您提供了一个相当简单的途径来开始迁移到 UWP。 如果您选择进行批发转换，则不再缺少 UWP。
更大的问题仍然是微软对下一步的真正含义缺乏明确性。 所有一直希望 XAML Nirvana 的人都放弃了 Silverlight 惨败，该惨败再次与 UWP 重演。
WinUI 显然是一个重新贴上标签的 UWP，亲眼目睹是痛苦的。 同样明显的是，微软希望我们都忘记 UWP 是什么。
尽管如此，微软的左手并不总是与右手正在做的事情保持一致。 WindowsX 使 Win32 及其附带的一切（WPF/Winforms/等）成为“可能”在其较低性能沙箱中运行的应用程序的微弱前景。 UWP 是并且目前仍然是 Windows 10、WindowsX 及更高版本的本机 UI。 WinRT API 是对 Win32 的重大改进。 所以我想你必须选择是要搬到 2020 年代还是坚持到 2010 年代。
Noemata
于 2020-03-08
WinUI 显然是一个重新贴上标签的 UWP，亲眼目睹是痛苦的。 同样明显的是，微软希望我们都忘记 UWP 是什么。
@Noemata WinUI 是基于 UWP API（XAML、Composition、Input...）的新产品。 这个名字很有意义，因为无论底层应用模型如何，您都可以使用它为 Windows 应用构建 UI。
我糊涂了。 您自己在最后一段中提到了 10X。 UWP 应用程序模型本身正在通过 Windows 10X 获得推动。 现在，10X 能否成功，只有时间才能证明。 但是 MS 在其消息中已经很清楚了：正如您所指出的，UWP 是 10X 的本机平台（与 Web 一样）。
Felix-Dev
于 2020-03-08
@Noemata到 2020 年赶上 2010 年可用的功能，我们中的许多人被迫留在 2010 年。
我们中的许多人刚刚厌倦了从放弃 Silverlight、XNA 开始的重写火车，并看到 MS 如何手动挥动 .NET Core、WinUI 所需的重写，同时在此过程中放弃了功能，并没有赢得我们许多人的心客户，拥有完全正常工作的应用程序，他们不明白为什么他们应该支付重写以获取更少的功能。
现在，由于拥有 Android 和 Windows 10 X 平板电脑的聪明才智，我们期待 Xamarin 和 PWA，而不是 WinUI。
pjmlp
于 2020-03-08
@pjmlp也许。 我很好奇你缺少什么功能？ 我已经将一些相当大的 WPF 应用程序移植到 UWP。 最令人头疼的是安全沙箱，以及学习使用它而不是对抗它。 以前缺少一些部分，例如数据网格、数据库连接、用于高速通信的良好 API 等等。 现在少的很少。 在 WPF 中，我几乎无法轻松做到很多事情。 公平地说，目前，通过利用对 WinRT API 的访问，我在 WPF 中没有什么不能做的，除了我会降低性能，因为 UWP 以更优化的方式编译为机器代码并使用更好的 DirectX 渲染堆栈。 另外，如果您打算保护您的 IP 或防止入侵者，您必须混淆您的 WPF 代码（使其更脆弱）。
手机/平板电脑是点解决方案类应用的绝佳设备。 我不想在手机上演奏交响乐，也不想设计摩天大楼，我宁愿能够将我的桌面应用程序的部分点解决方案部分定位到移动设备上，而不是尝试让移动设备在我的桌面上工作。
@Felix-Dev 我明白 WinUI 是什么。 我质疑为什么仅仅因为 WPF、Winforms 和 MFC/Win32 开发人员不接受它就需要另一个分支。 更好的策略是让移民更具吸引力或不那么痛苦，或两者兼而有之。
微软在 UWP 上做了很多正确的事情。 有大量示例应用程序涵盖了各种用例。 他们来晚了，缺少的功能也是如此。 真的太晚了吗？
Noemata
于 2020-03-08
@Noemata WinUI 可能会以任何一种方式发生（有或没有 WinUI 桌面），因为将 UWP UI 堆栈与操作系统分离是绝对必要的步骤。 如果 WinUI 在 Windows 10 首次发布时就已经存在，那将是最好的，但有一些原因表明情况并非如此。
至于是不是太晚了……我们在UWP社区discord频道里有过很多这样的讨论，也有过无数次的热情交流。 我们中的一些人认为这艘船已经启航，而另一些人仍然认为 UWP 平台/WinUI 有机会成长和成熟成为主要的开发平台。 许多人有很多想法，MS 的最佳方法可能是什么样子（即是否去 xplatform？）。 事实上，该团队目前正在努力开发 WinUI 3，它的发布将标志着开始迎接真正的挑战：在社区的帮助下推动 WinUI 向前发展，使其成为面向 Windows 的开发人员的首选框架.
Felix-Dev
于 2020-03-08
@Noemata ，首先与 Telerik、Component One 等现有的第三方组件库兼容...
然后不必重新编写任何东西，如前所述，我们厌倦了重写。
在 DirectX 方面，不仅不支持 WPF 中的 3D 建模类，我们还希望编写 C++，因为 Microsoft 懒得为 DirectX 创建运行时投影，而且有点令人愉快的 C++/CX 方言被冗长的语言所取代C++/WinRT 能力较差，但更好地兼容。
最重要的是，我们不仅必须丢弃完美运行的 WPF 代码，我们还必须对 WCF、EF6 代码做同样的事情。
我仍然相信 UWP 是比 Win32 更好的 API，不知怎的，Longhorn 应该是这样的，但这种方式已经烧毁了太多的桥梁，因为微软已经烧掉了许多组织的重写预算。
pjmlp
于 2020-03-08
@pjmlp ，这些都是带有相当温和的反驳论点的好点，所以我什至不会尝试。 不支持 WPF 3D API 对我个人来说是一个很大的打击。 考虑到 3D 的 WPF 绑定选项，不得不学习一种新方法并不有趣，而且能力也差了很多。 UWP 下 3D 的 C# 替代方案已经存在，只是在您体验了绑定到 3D 模型的好处后，它的用处就会大大降低。
C++/CX 是另一个需要很长时间才能被 C++/WinRT 解决的痛点，它可能会在下周的某个时间保持稳定（它仍在变化）。
WCF 已死（抱歉，新选项要好得多）。 EF6 应该有一个更好的迁移故事。 你在重写预算惨败@pjmlp上是绝对正确的，显然这是微软曾经得到的东西，并且不再关心考虑到技术的疯狂/不一致的流失。
@Felix-Dev，您也提出了完全有效的观点。 UI 解耦应该从一开始就存在。 要求基于 XAML 的 xplatform UI 的人应该重新表达他们的要求，并要求在他们选择的平台上使用 XAML 渲染引擎和一个迷你操作系统来复制 API 表面（另一个 Java/Silveright/Uno Platform/Unity/Whatever ......最终以接近金属应用无法开始考虑的 HTML 结尾）。 我目前不了解最新的 MS 内部计划。 往里看，WinUI 是一面飘扬的旗帜，表明船正在再次被纠正（还有多少次？）。 随着 Silverlight 的死亡，保卫微软变得不可能。 我不会再拿起那把剑了。 我想我真正在做的是哀叹 UWP 的死亡 :-( ... 痛苦。https://www.youtube.com/watch?v=uBiewQrpBBA
查理 == 微软
Noemata
于 2020-03-08
跨平台？ 微软应该只买 UNO 就可以了。
shaheedmalik
于 2020-03-09
跨平台？ 微软应该只买 UNO 就可以了。
我希望无论出现什么解决方案，它都不会依赖于网络浏览器或某种网络视图。 在平台的本机窗口或 UI 界面中显示 UI - 但看起来与在 Windows 上的相同。
mdtauk
于 2020-03-09
跨平台？ 微软应该只买 UNO 就可以了。
我希望无论出现什么解决方案，它都不会依赖于网络浏览器或某种网络视图。 在平台的本机窗口或 UI 界面中显示 UI - 但看起来与在 Windows 上的相同。
除了在 Windows 7 上之外，UNO 就是这样做的。Windows 7 是唯一的例外，因为它使用 Web 浏览器。
shaheedmalik
于 2020-03-09
对于那些需要跨平台桌面解决方案的 WPF 开发人员来说，Wine 可能是一个可行的选择。 我已经成功地将大型 WPF 应用程序（主要是 .NET Core WPF）移植到使用 Wine 在 Linux 上运行。 我有一篇文章可以帮助您入门：
https://ccifra.github.io/PortingWPFAppsToLinux/Overview.html
我也开始将一些 WinForms 应用程序移植到 Linux。 到目前为止，我还没有遇到任何问题。
Wine 还应该使您能够在 Mac、Chrome OS 和 Android 上运行。 我只尝试过Linux。
对我来说，这表明使用 DirectX 作为抽象层是可行的，并且是一个可行的模型。 我怀疑一旦 .NET WASM 更加成熟，它甚至可以在带有 WebGL 的 Web 上运行良好。
让微软在 Wine 方面提供帮助（至少确保他们不会破坏它）会有很大帮助。 他们可以帮助使用 WineLib 创建一个真正的本地解决方案，并且鉴于他们的专业知识，我认为这不会是太多的努力。
ccifra
于 2020-03-19
AvaloniaUI 已经是跨平台的。 为什么不向项目中的人寻求帮助和反馈来改进 WinUI？
好吧，不如 Uno Platform。 Uno Platform 也可以在 Web 上运行 (WASM)。 Avalonia 缺乏这种能力。
weitzhandler
于 2020-03-27
Avalonia 还使用它自己的 XAML 方言，这是 Uno 试图避免的。
来自：Shimmy [email protected]
发送时间：2020 年 3 月 27 日星期五 4:09:30 AM
致：microsoft/microsoft-ui-xaml [email protected]
抄送：夏普忍者[email protected] ; 评论[email protected]
主题：回复：[microsoft/microsoft-ui-xaml] 讨论：WinUI 应该是跨平台的 (#2024)
AvaloniaUI 已经是跨平台的。 为什么不向项目中的人寻求帮助和反馈来改进 WinUI？
好吧，不如 Uno Platform。 Uno Platform 也可以在 Web 上运行 (WASM)。 Avalonia 缺乏这种能力。
—
您收到此消息是因为您发表了评论。
直接回复此邮件，在 GitHub 上查看https://github.com/microsoft/microsoft-ui-xaml/issues/2024#issuecomment-604893750 ，或取消订阅https://github.com/notifications/unsubscribe-auth/ AD3GCLE3TEC3DZO74OXKX73RJRUMVANCNFSM4K3JAUQA 。
sharpninja
于 2020-03-27
WinUI的大部分技术都来自于Sliverlight，而Sliverlight实际上已经实现了跨平台。 所以WinUI跨平台靠的是策略，不是技术。
binsys
于 2020-06-03
老实说......实际上微软现在试图追赶它真是太可怜了......他们只关心“大”市场份额，他们并不关注他们的客户/产品粉丝想要什么。
微软是 DESKTOP APP 开发转向过时的 WEB 开发的原因，即使 web 如此可怕。
我确信每个 XAML 开发人员都同意 HTML/CSS 是如此垃圾。
但仍然... HTML、CSS、DOM... 使用 React、Angular、Vue 等框架，他们正试图让它变得更令人愉快。 人们仍然关注这个过时的网络，而不是微软新的闭源 Windows 平台，它每 2-4 年就会死掉一个新平台。
基于 XAML 的 Win-app 平台应该在几年前就已经开源。 它应该在网站、Windows、Mac、Linux、Android（客户想要的任何平台）上部署一次。 Windows 应用商店应该是带有 XAML/UWP 应用呈现器的跨平台。 （类似于 Google Chrome 与 HTML/CSS 渲染器的跨平台方式）。
在微软的黄金时代，一个基于 XAML 的跨平台应用程序可能已经摧毁了 Web，然后我们就不必处理这些 CSS、HTML、DOM 和无数框架。
但不，微软对专有软件的痴迷使他们输给了网络。
与此同时，Google 的 Flutter 正在成为我一直想要的 XAML。
Qws
于 2020-06-03
我希望 WinUI 3 将成为 MAUI 的目标平台。 Uno平台已经宣布支持WinUI 3 Preview。
那么， @jeromelaban / Microsoft 我们可能真正需要的是 Uno/MAUI 统一？ MAUI 在 IMO 上不如没有 Web（浏览器）目标的 Flutter 或 Uno 有用。
也请在MAUI 存储库中留下您的评论。
WPF（Silverlight）无处不在！
tomasfabian
于 2020-06-18
将 DirectX 移植到其他平台似乎是一项艰巨的工作，也许解决方案是使用 OpenGL 或 Vulkan 而不是 DirectX
Google 拥有 ANGLE，它允许通过将调用和着色器转换为本地 API（桌面 gl [可能由 swiftshader 软件渲染器提供]、vulkan、directx、metal）在任何平台上本地运行 OpenGL ES。 它也是 Chrome 和 Flutter 的核心部分，与 Skia 一起运行。
微软可以为 GUI 应用程序制作 DirectX 的一个小子集（也许只是作为一个起点），并像 ANGLE 一样将其转换为原生 API。
handicraftsman
于 2020-07-21
至于“不同的 linux 发行版支持”问题，linux 用户通常足够熟练，可以自己修复不兼容问题，即使这样，Flatpak 也可以统一桌面打包，就像 Docker 为服务器打包一样。
handicraftsman
于 2020-07-21
theromis
于 2020-08-03
我真的认为 WinUI 还应该支持 Mac 和 Linux 上的原生主题，同时仍然支持自定义主题。
我不确定 Mac 用户，但 Linux 社区喜欢控制他们桌面的外观。
他们已经有了 Gtk，我认为将其包装到 WinUi 框架中是一件好事
Shadowblitz16
于 2020-11-07
我真的认为 WinUI 还应该支持 Mac 和 Linux 上的原生主题，同时仍然支持自定义主题。
我不确定 Mac 用户，但 Linux 社区喜欢控制他们桌面的外观。
他们已经有了 Gtk，我认为将其包装到 WinUi 框架中是一件好事
由于 WinUI 是一种样式语言，因此这绝对很难做到，而底层 XAML 框架要求您自己进行主题化，同时还提供了默认主题化。
handicraftsman
于 2020-11-07
我过去曾建议，该项目的结构应使社区能够开发适用于 macOS 和 iOS 的 Metal Renderer - 可能还有适用于 Android 的 Skia 渲染器。
可以在所有平台上使用相同的默认样式和模板，或者可以创建 Android 和 macOS 样式的默认模板和资源。
mdtauk
于 2020-11-07
相关问题
ratishphilip
·
3评论
cosminstirbu
·
3评论
BrandonKuenzi
·
3评论
MuziburRahman
·
3评论
ocalvo
·
3评论
最有用的评论
我认为值得一提和提醒的是，谷歌正在开发 Flutter，他们并没有将其称为 GoogleUI 或 AndroidUI。 它适用于任何地方——甚至在网络和桌面上。 我这么说是因为似乎有“让它在 Windows 上运行”的倾向，但如果存在另一个更便宜、更快、更易于使用的竞争产品，并且可以在 Windows + 其他所有东西上运行......开发人员会怎么做（和相应的市场）选择？ 作为一个小企业主，我可以告诉你，考虑到这两种选择，我知道我将投资放在哪里。