Maui: .NET 5 的跨平台 UX

我喜欢这个主意。 但是，实际上，它更有可能由 Xamarin.Forms 团队处理。
也许，Core 团队会贡献一些低级结构来使 UX 框架“更好”（就像 CoreFxLab 所做的那样）。

编辑：WebAssembly 也可以成为受支持的平台吗？

我喜欢这个主意。 我已经看到人们（包括我自己）在多种环境中使用多种 UI 技术。

我敢肯定，在可预见的未来，我们会看到 .net 核心被移植到 Android 和 iOS 设备上，使用 Native 应用程序替代corehost 。 话虽如此，将需要 UI 功能。

对于 2D xplat 绘图库（包括加速绘图），我们有 Skia 例如。

在所有情况下，我相信 XAML-Standard 将是一件好事，以便实现一种标准方式来“描述”UI 以及 Fluent Design 指南。

但是，我怀疑 .Net 团队是否有任何计划在这方面投入时间，而不仅仅是带回一些 xplat System.Drawing.X原语......

@4creators也许你对这个讨论感兴趣

@vibeeshan025 WebAssembly不是JavaScript 的替代品，因此您的大部分评论都没有任何意义。 您仍然需要 JavaScript 来将 WebAssembly 与 DOM 连接起来。 所以，不，你不能只是将某些东西编译成 wasm 并期望它用 JavaScript 替换你之前所做的任何事情。 这不是它的工作原理。 它不会是一种 UI 技术。

嘿，伙计们，只想把我的 5c 放在这里。
System.Drawing.X 对于 .NET Core 开发至关重要。 （刚从 https://github.com/dotnet/corefx/issues/20325 来到这里）

从 UI 开始 - 询问 Web（前端）开发人员。 他们使用了许多现代技巧，例如热重载。
我个人喜欢 React/ReactNative 的进展情况。 使用 C# 编写 React 然后为不同的平台使用各种渲染引擎会很棒。

FWIW， Mono 正在采用 WebAssembly ，所以如果它在 Mono 中工作，它在 WebAssembly 中工作（或将工作）。 至少，这是目前的想法/理解。

此外，我必须回应对 .NET/MSFT 完成这项任务的可能性的看法。 他们所有的关注点/智商都被放在了核心/内部/框架/只是让它工作，我认为这种方式将持续一年左右。 但谁知道呢，我可能会（愉快地）感到惊讶。

我对此的看法是，一些外部努力将会获得动力，并且可能会被 MSFT ala Xamarin 收购，但更多地关注 UI（而不是关注框架/工具，这是 Xamarin 的核心优势 IMO）。 因此，像Avalonia或Noesis这样的东西，分别通过开源和付费渠道提供他们的价值主张。 顺便说一句，这两个都是内置/支持 Mono。

Xaml 标准随着 Xamarin.Forms 的XAML 标准（预览版）的发布和项目进度的长期更新而有所改变。 PR dotnet/designs#111 中有一个关于项目目标的非常有趣的讨论，似乎朝着有利于该提案的方向发展

Silverilght 是一个很好的解决方案，代码已经存在

1. 开源silverlight代码
2. Makte 它在 dotnet 核心运行时之上运行
3. 使用月光进行 linux 分发
4. 为“Electron”创建 dotnet 核心替代品，它将覆盖整个世界（更少的内存使用 + 巨大的性能改进 + xaml 的优点）
5. 原生编译（如果有一天 corert 项目看到了曙光）

发现它相关- http://platform.uno

@gulshan有趣，伟大的项目，它是否支持大部分 UWP 功能，他们如何能够在很短的时间内实现如此丰富的功能集，而只有 4 个贡献者。

@vibeeshan025他们有一家公司资助它 IIRC ......

另一个值得探索的未来——HTML/CSS + .net（而不是 JS/TS）。 已经在这里尝试了-
https://github.com/SteveSandersonMS/BlazorElectronExperiment.Sample

经过研究，似乎 tcl/tk 可能是所有平台的 gui 选项。 不确定 Windows 上的 tcl/tk 是否会调用实际的 gdiplus 内容，但它可能是将 WPF 和 Winforms 带到 Linux、Mac、Windows、Android？、iOS？甚至是 webforms 的一个选项？ 不确定 tcl/tk 是否支持最后 3 个。 如果它这样做了，那么使用基于它的单个代码库就可以更容易地维护 GUI。

可能使用的 GUI 库：

• TclBridge （似乎不是免费或开源的）
• Mono 一个（可能是最好的）
• 鹰（不知道它有多好）
• 也许其他人也是如此。

我从 cpython 的 tkinner 模块中得到了使用 tcl/tk 的想法。

也不确定 .NET Core 是否支持从 *.resources(compiled resx) 甚至从 *.resx 加载资源。 如果是这样，那就太好了。

Microsoft.DesktopUI.App目前 v3.0.0-alpha-26921-3 可用于每日构建的 Windows .NET Core SDK 。 我很好奇在 GDC 和 DirectX 的一些翻译层下在 Linux 上启动和运行它需要什么。

它需要的不仅仅是跨平台的 UX，它需要是一个跨平台的应用程序开发框架。
将其限制为仅 UX 是错误的。 它至少应该具有 SilverLight + RIA-Services 的所有功能。
当您为将存在数十年的大型公司编写庞大的自定义系统时，您需要保持所有选项开放，因为您不知道一年（或 10 年内）会添加哪些要求，因此封闭且有限的环境像 UWP 永远不会被考虑，与在浏览器中运行的东西一样。 必须对不同平台上的每个功能、API 和服务进行完全、无限制和本地访问。
当您开发一个同时编写服务器和客户端的系统时，您不想使用 REST 或类似的东西（打算在您编写服务器时使用，而其他人编写客户端时使用），相反，它应该本着 RIA 的精神，您可以在其中定义服务器 API，然后使用与服务器上相同 (===) 的类和方法从客户端自动调用它。 一切都需要强类型。 数据验证从从 SQL 服务器（或您正在使用的任何数据源）中的字段获得的硬限制开始，并通过 DataAnnotations 进行扩展，它会自动传播到客户端（考虑到本地化）。

这是所需要的，没有什么是可以接受的：
创建无处不在的 .NET 客户端应用程序开发模型

自 Visual Basic 6 发布到现在已经 20 年了，我们离 1998 年的生产力还差得很远。微软需要展示他们对如何在“微软世界”中完成更大的定制系统以及他们将如何恢复我们 20 年前的生产力的愿景。

微软需要振作起来，站出来接受他们所承担的责任。 微软需要意识到，几十年来在 MS 技术上投入巨资的所有客户、合作伙伴和开发人员都深感失望，他们对 MS 的信任度非常低。 MS 需要开始尊重他们的客户、合作伙伴和开发人员，并重建他们的声誉和尊重，但看看他们现在对 Skype 所做的事情以及他们如何对待他们的 Skype 客户和用户，我不太希望这会发生。

忘记 Xamarin，微软自己甚至不使用它，而是选择像 ElectronJS 框架（基于 Chromium、Node.js、JavaScript 和 CSS）这样的单线程内存占用框架，而不是使用他们拥有的 Xamarin完全控制，并且将为每个平台生成真正的本机代码。

@Bartolomeus-649

自 Visual Basic 6 发布到现在已经 20 年了，我们离 1998 年的生产力还差得很远。

计算机和互联网使用的普及以及平台的多样性（操作系统/移动性/外形尺寸）远没有 1998 年那么低。

我觉得你要求的是“有人来解决你所有的问题”。 这种多样性存在的原因是多方面的，否则我们都将使用具有相同操作系统的相同设备。 构建“对所有事物的抽象”很难，而且通常只会为您提供最小的功能集。 Xamarin 仍然是这里的最佳方法，允许您尽可能使用特定于平台的 API。 但即使是对移动应用程序的良好抽象也可能无法帮助您实现高生产力的桌面应用程序。

关于您提出的其他观点，我认为这些主要是适用于您的特定工作的个人意见或观察，而不是普遍适用的陈述。

我确实希望我们能获得更好的跨平台体验，但我认为这并不容易，也不会经受住时间的考验。 即使 WebAssembly 和类 Electron 的 shell、PWA 和朋友在未来 5 年内发展为首选解决方案，我们可能会在 20 年内做一些完全不同的事情（然后我们会抱怨 2018 年的事情多么容易😂 ）。

Microsoft 不辜负我们的期望并开源了 UX 框架。 我们现在可以启动社区项目，将它们移植到其他平台。 不幸的是，微软已经明确表示他们不打算在任何端口上工作，所以这项工作似乎留给了社区。

@richlander @karelz @AdamYoblick @llongley @kmahone

我的问题是，如果我们 - 社区可以在现有存储库中的 Linux 和 macOS 端口上工作，即在单独的分支中，还是我们应该创建单独的存储库来支持此类项目？ 这是非常重要的决定，因为使用现有的 repos 将允许我们将端口与 MSFT CI 基础设施集成，否则必须由社区从头开始设置。

Xamarin.Forms/Avalonia/Platform.Uno 是否有理由不满足您的需求？ 似乎带来跨平台 XAML 的新尝试对整个社区几乎没有价值。

不是 4creators，而是我的 2 美分/印象：

• Xamarin.Forms 似乎主要关注移动场景。
• Platform.Uno 也一样
• Avalonia 还没有准备好迎接黄金时段。 太麻烦了，我不想相信它。 （上次我去检查它，演示应用程序甚至不会在当前的稳定版本中构建，并不能完全激发信心。）

我并不是说 WPF 或 Winforms 的跨平台端口是这里的解决方案。 （首先，与 API 兼容的 Winforms 跨平台端口甚至不是一个好主意，IMO。对 WPF 没有评论。）但是，我认为现有的解决方案也不适合桌面应用程序开发。

好点。 尽管如此，我们应该专注于改进现有的解决方案，而不是构建另一个解决方案，这比前者成本高得多。

顺便问一下，关于 NoesisGUI 有什么痛点吗？

社区可以在 Linux 和 macOS 端口上工作

@4creators创建您拥有并完全控制的分叉。

持续集成基础设施

.NET Core CI 基础设施正朝着使用常规 Azure DevOps 的方向发展，而不是当前基于 Jenkins 的自定义解决方案。 Azure DevOps 为您可以利用的开源项目提供免费服务。

仅针对 dotnet/winforms 发言：

Winforms 已经在使用 AzureDevOps，任何 PR 到 master 都会自动运行 PR CI 构建。

但是，我很确定任何工作都必须在叉子中完成。 我们不打算授予对 dotnet/winforms 的写入权限，以便人们可以创建自己的分支。 有了所有的公共贡献，这将对我们的回购造成相当大的污染。 :)

顺便问一下，关于 NoesisGUI 有什么痛点吗？

不知何故，NeosisGUI 从我在各种 UI 框架上的笔记中幸免于难，所以我不得不再次查看它。

我没用过，虽然我一直想试试。 我的印象是它是为了支持游戏内的 UI，所以它可能不适合工具。 （尽管查看控件列表，这可能是一个错误的假设。）对于游戏内 UI，我们的需求并不能证明未来的成本是合理的。 无论出于何种原因，它也不支持 Nintendo Switch。 （虽然显然这是一项正在进行的工作。）

@4creators我认为这个问题的标题是错误的，因为混淆了两个问题。

首先，允许 .Net UI 框架使用 .Net Core 而不是其他 .Net 运行时。 WPF 现在可以在 .Net Core 上运行，他们也可以让 Xamarin.iOS/Android/Mac/GTK 也可以在 .Net Core 上运行。 与使用 Mono 或 .Net Framework 相比，这具有性能和维护优势。

然而，这样做并没有创建一个新的跨平台 UI 框架。 您引用的线程和此处的大多数帖子都是关于创建新的跨平台 UI 框架的。 运行时不是这里的主要问题。 然而，这些线程非常混乱，因为它们没有解决实现跨平台 UI 的实际困难，而实际实现（主要使用本机控件的 Xamarin.Forms 和使用通用呈现的 Avalonia）已经解决了这些问题。

最好通过添加相关的桌面控件（不难）来改进 Xamarin.Forms 桌面功能，或者如果您愿意，可以帮助使 Avalonia 稳定。 任何新平台（即使它基于现有的单平台平台）都需要多年的工作才能达到 alpha 质量，而重做 Xamarin.Forms 和 Avalonia 而不是为它们做出贡献的唯一理由是它们都在这样做错误的。

我同意后半部分。 但是， Xamarin 团队明确表示，用 .NET Core 替换 Mono 是不可行的，因为它们针对不同的工作负载进行了优化，并且需要完成重要的重要集成工作。

我认为这个问题的标题是错误的，因为混淆了两个问题。

@charlesroddie IMO，不是真的。 关键不是在 .NET Core 平台上提供一些 UX 框架，而是作为 DotNet 生态系统一部分的 UX 与其他部分共同创建和维护。 MSFT 对 .NET 生态系统的未来计划是基于 .NET Core 的 .NET Framework 已被弃用为不推荐用于新应用程序开发的旧版 Windows 组件。 目前没有将 Xamarin.Forms 移植到 .NET Core 的计划，上述原因由@Happypig375指出，另一个原因是缺乏决定如何在移动设备上继续支持 xplat。 但是，我确实假设由于对 .NET Core 的开发投入，MSFT 使用的未来 xplat 平台将基于 .NET Core。

即使在 Linux 上，Mono 也没有针对许多工作负载进行足够优化，并且不再有在该运行时之上开发的主要新功能。 BCL 当前在 Mono 和 .NET Core 之间共享。 这表明 Mono 将来被弃用的可能性很高。

基于这个假设，我认为将基于 .NET Core 的单一 UX 平台作为其生态系统的一部分是值得的。 因此，问题标题完全应该是这样，因为我不要求某些 UX 框架，它是 xplat 和基于 CLI 标准，而是要求 UX 框架，它是 DotNet 团队设计和支持的 .NET Core 生态系统的一部分。

.Net Standard 确保 UI 不同的运行时可以毫无问题地成为同一生态系统的一部分。 尽管 .Net Core 与其他运行时相比具有优势，最终可能会贬值，但没有必要将运行时与找到正确的跨平台 ui 方法联系起来。 它只是使问题过于复杂。

说 UX 平台“基于”特定的运行时，这太过分了。 @Happypig375 Xamarin 目前没有计划切换到 .Net Core（计划是通过共享代码让 Mono 变得更类似于 .Net Core）。 但这应该不会比将 WPF 迁移到 .Net Core 更难。

（顺便说一句，Mono 没有新功能是不正确的，因为它正在更新以支持 .Net Standard 2.1，并且当前关于 webassembly 的工作是在 Mono 而不是 .Net Core 中完成的。但这是一个旁白，因为这项工作可以移植到 .Net 核心。）

WinUI 3.0 路线图 - 我们需要您的意见！

一旦所有必需的组件都开源了，这个开发提案似乎可以打开新的 xplat 可能性。

如果是这种情况，他们应该考虑将其称为MicrosoftUI 1.0 ，@4creators。 😆

> * https://github.com/Microsoft/microsoft-ui-xam
-------------------------------------------------^ missing l

我相信这个 repo 解决了这个问题。