如果您查看该项目，您会发现它分为几个子项目，CNC 核心项目是中心部分。GrblViewModel.cs解析来自 grbl 的消息，并通过事件将数据更改分派到程序的其他部分——这是使用 C# MVVM 设计模式的基础。这意味着 UI 已经与核心业务逻辑很好地分离。

我不知道将其移植到另一种语言需要做多少工作，如果要完成，则必须由熟悉该语言和相关库的人完成。但是，我可以尝试支持任何想试一试的人。

然后其他人可以介入并在顶部固定一个新的 UI，然后就此结束。

这听起来很简单，但在我看来并非如此。我花了很多时间才让发件人到达今天的位置。其中很大一部分用于研究如何做事（这是我的第一个 WPF 项目）和测试。我太老了，不能用新的语言/框架重新开始——我想和你们大多数人一样，想花时间在研讨会上……

好吧，核心必须从对 Windows 库的引用中清除，才能开始向 Linux 的移植过程。我打开的第一个文件
使用 System.Windows.Media.Media3D；

所以我认为我们可以从理想主义的未来观点转向更现实的观点，看看我们可以用最少的工作量改进什么。让我们关注花费最多时间的主要“grbl”视图。

对我来说，所有这些弹出视图都应该保留在主视图的左右栏中。有足够的空间，尤其是在左列中，可以添加 MPos 下拉列表并将慢跑视图添加到右视图中。

为用户界面添加颜色也会让它感觉更生动。因此，作为一个简单的开始，您可以开始向整个 UI 中一致使用的轴添加颜色。一个简单的建议是从 Fusion360 复制颜色（x=红色，y=绿色，z=蓝色）。使用这些颜色，可以为 DRO、MPos 中的标签和点动视​​图上的点动按钮着色。

我昨天第一次使用中心取景器视图。我没有意识到这两个图像是可选的。它们看起来就像只是解释运动的图像。对我有很大帮助的是一个清晰的视觉指示，表明其中一个选项已被选中。因此，与其让选择颜色成为灰色海洋中的深灰色，不如让选项周围的浅蓝色框更清晰。 当然，那里有文字说明它是可选的。但是，每当您必须添加文本来解释用户需要做什么时，这就是一个危险信号。相反，您可以考虑如何通过更改 UI 来让用户更清楚地了解他们需要做什么。例如，我只阅读了红色文本，根本没有处理黑色文本。

如果有一个在 Linux 上运行的版本，那就太棒了。我可以看到使用 RasPi 连接到 grblHAL 板，特别是通过以太网以获得更好的可靠性。希望它可以以允许可以跨不同操作系统使用的附加组件/插件的方式构建。

好吧，核心必须从对 Windows 库的引用中清除，才能开始向 Linux 的移植过程。

您不能只是“清理”对 Windows 库的引用——您要么必须从头开始编写替代代码，要么找到与为项目选择的语言兼容的现有代码（我假设不是 C#）。或者放弃图书馆提供的功能……

对我来说，所有这些弹出视图都应该保留在主视图的左右栏中。有足够的空间，尤其是在左列中，可以添加 MPos 下拉列表并将慢跑视图添加到右视图中。

“标准”版本的最低屏幕分辨率要求没有任何可用空间，但XL版本有这样的布局。

为用户界面添加颜色也会让它感觉更生动。

有些人可能喜欢那样，我不喜欢。要添加的更多配置选项（皮肤？）。

因此，与其让选择颜色成为灰色海洋中的深灰色，不如让选项周围的浅蓝色框更清晰。

是的，也许是这样。和上面的论点一样吗？UI 设计很难——我不是这方面的专家。

有一个在 Linux 上运行的版本会很棒

我同意，有没有人准备好迎接挑战？我很聪明，不会自己开始这样做，因为我很清楚这会有多少工作（至少对我来说 – 学习一门新语言，研究要使用的图书馆等等）……

刚刚偶然发现了这张票。对我来说，尝试使用Mono使其工作比尝试固定在某些 Python UI 上似乎更有意义。拥有一个单独的用户界面并“收工”听起来很不现实。这不是一项快速的任务——但 Mono 可能仍然是最简单的。只是我的 2 美分。

@tcurdtMono 不支持 WPF（也不支持所使用的 MVVM 设计模式？）所以这不是一种前进的方式，除非像第一个版本那样将其移植回 Forms 应用程序。

只是为了提供一些背景信息： https: //www.mono-project.com/docs/gui/wpf/

目前，Mono 项目中没有任何小组计划将 Windows Presentation Foundation API 作为项目的一部分来实现。
…
在这一点上，我们强烈建议对 WPF 感兴趣的用户改用 Xamarin.Forms，因为它提供了一组丰富的跨平台 API 和功能（并且也有一个 WPF 驱动程序）。

伤心 – 但听起来你可能是对的。也是一项更大的任务。

好吧，核心必须从对 Windows 库的引用中清除，才能开始向 Linux 的移植过程。

您不能只是“清理”对 Windows 库的引用——您要么必须从头开始编写替代代码，要么找到与为项目选择的语言兼容的现有代码（我假设不是 C#）。或者放弃图书馆提供的功能……

对我来说，所有这些弹出视图都应该保留在主视图的左右栏中。有足够的空间，尤其是在左列中，可以添加 MPos 下拉列表并将慢跑视图添加到右视图中。

“标准”版本的最低屏幕分辨率要求没有任何可用空间，但XL版本有这样的布局。

为用户界面添加颜色也会让它感觉更生动。

有些人可能喜欢那样，我不喜欢。要添加的更多配置选项（皮肤？）。

因此，与其让选择颜色成为灰色海洋中的深灰色，不如让选项周围的浅蓝色框更清晰。

是的，也许是这样。和上面的论点一样吗？UI 设计很难——我不是这方面的专家。

有一个在 Linux 上运行的版本会很棒

我同意，有没有人准备好迎接挑战？我很聪明，不会自己开始这样做，因为我很清楚这会有多少工作（至少对我来说 – 学习一门新语言，研究要使用的图书馆等等）……

选择 C# .NET 是个错误，它不是跨平台的

选择 C# .NET 是个错误，它不是跨平台的

说起来容易，但请考虑替代方案。如果 .net 库和 C# 不可用，则可能不会创建 ioSender。可移植性问题是一个更可取的结果。

我写了几十年的软件，现在需要付出很多努力。Terje 在自己的时间免费完成了这项工作。Windows 是供个人使用的较流行的操作系统之一。我的 HMI 也运行在 windows 平台上。

支持他创建和维护它。如果有人想将它全部移植到 Java，那就试试吧。

选择 C# .NET 是个错误，它不是跨平台的

说起来容易，但请考虑替代方案。如果 .net 库和 C# 不可用，则可能不会创建 ioSender。可移植性问题是一个更可取的结果。

我没有批评或指责“Terje”，而是说选择c#开发iosender的决定是个错误，我选择了QT开发的candle2，它是跨平台的，可以在windows、linux上运行，尤其是在嵌入式linux上运行，我已经测试过在树莓派 4 上使用 stm32 MP157 运行，它们运行良好并且具有 3D 图形

选择 C# .NET 是个错误，它不是跨平台的

说起来容易，但请考虑替代方案。如果 .net 库和 C# 不可用，则可能不会创建 ioSender。可移植性问题是一个更可取的结果。

我没有批评或指责“Terje”，而是说选择c#开发iosender的决定是个错误，我选择了QT开发的candle2，它是跨平台的，可以在windows、linux上运行，尤其是在嵌入式linux上运行，我已经测试过在树莓派 4 和 stm32 MP157 上运行，它们运行良好并且具有 3D 图形

选择 C# .NET 是个错误，它不是跨平台的

说起来容易，但请考虑替代方案。如果 .net 库和 C# 不可用，则可能不会创建 ioSender。可移植性问题是一个更可取的结果。

我没有批评或指责“Terje”，而是说选择c#开发iosender的决定是个错误，我选择了QT开发的candle2，它是跨平台的，可以在windows、linux上运行，尤其是在嵌入式linux上运行，我已经测试过在树莓派 4 和 stm32 MP157 上运行，它们运行良好并且具有 3D 图形

有点敏感？我是在回应对选择 C# 的批评。在我的评论中，我没有说过任何关于你批评 Terje 的事情。

然而，既然你提出来了，我发现很难不在你原来的评论中看到对他的批评。

然而，既然你提出来了，我发现很难不在你原来的评论中看到对他的批评。

什么？相反，我一直称赞Terje和grbl的原作者是最伟大的挪威人

grbl让3d打印非常强大

选择 C# .NET 是个错误，它不是跨平台的

说起来容易，但请考虑替代方案。如果 .net 库和 C# 不可用，则可能不会创建 ioSender。可移植性问题是一个更可取的结果。

我没有批评或指责“Terje”，而是说选择c#开发iosender的决定是个错误，我选择了QT开发的candle2，它是跨平台的，可以在windows、linux上运行，尤其是在嵌入式linux上运行，我已经测试过在树莓派 4 和 stm32 MP157 上运行，它们运行良好并且具有 3D 图形

有点敏感？我是在回应对选择 C# 的批评。在我的评论中，我没有说过任何关于你批评 Terje 的事情。

然而，既然你提出来了，我发现很难不在你原来的评论中看到对他的批评。

grbl让3d打印发展的生态空前强大，但在CNC却不容乐观。想贡献一点自己的力量帮助grbl在CNC的开发上。我自学了一点电子技术和绘制 PCB。我做了基于esp32grbl和grblhal的板子出售，录了一些grbl教程，我应该是个好人吗？

选择 C# .NET 是个错误，它不是跨平台的

说起来容易，但请考虑替代方案。如果 .net 库和 C# 不可用，则可能不会创建 ioSender。可移植性问题是一个更可取的结果。

我没有批评或指责“Terje”，而是说选择c#开发iosender的决定是个错误，我选择了QT开发的candle2，它是跨平台的，可以在windows、linux上运行，尤其是在嵌入式linux上运行，我已经测试过在树莓派 4 和 stm32 MP157 上运行，它们运行良好并且具有 3D 图形

有点敏感？我是在回应对选择 C# 的批评。在我的评论中，我没有说过任何关于你批评 Terje 的事情。

然而，既然你提出来了，我发现很难不在你原来的评论中看到对他的批评。

谷歌翻译可能会带来一些误解？我的母语是中文

我偶然发现了https://github.com/avaloniaui/avalonia并且只记得这张票。
这可能是一个选择吗@terjeio？