创建于2022年5月14日

我从80年代开始编程，最近评估了使用Go编写GUI程序的选项。我主要对跨平台的桌面GUI软件感兴趣，尽管使用相同技术的移动版本也很吸引人。任何可以让程序员节省精力的东西都很吸引人。

我的调查结果是，目前还没有适合Go的好的GUI选项。这很不幸，因为除此之外，Go将是易于使用的快速应用程序开发的完美替代品，就像我之前使用的REALBasic一样，现在已经变成了价格昂贵的Xojo。到目前为止，没有任何框架或语言+IDE+框架组合超过了我在REALbasic中体验到的生产力。我尝试过Lazarus，但Object Pascal不是一个好的替代品，该语言过于老旧，有时需要手动管理内存，这对于桌面GUI应用程序来说有很多缺点。我本可以从我喜欢和熟悉的其他语言中选择另一种语言。Racket有一个非常完整的GUI。我在其中编写和维护GUI应用程序已经很多年了。但是，我已经远离它，因为其中的GUI应用程序可能会感到迟缓，而且应用程序启动时间使Racket成为“快速”小型GUI应用程序的次优选择。Ada感觉像是你正在投资技术债务，缺乏第三方支持。它唯一的半路好的GUI选项是GTK3。尽管我多年来一再尝试CommonLisp，但它仍然感觉很麻烦，我发现它可用的第三方库缺乏文档和可信度。至于Rust，我已经学会了它，从头到尾阅读了Klabnik & Nichols的书，我不得不承认我觉得Rust不吸引人，而且过度工程化。它的可用性对于高完整性系统是值得怀疑的——我仍然建议使用Ada/Spark，它对于GUI编程没有优势，并且有一个总体上有毒的社区。

因此，最终选择了Go作为一个较大项目的编程语言，并且必须选择一个GUI库。以下是截至2022年5月的Go GUI框架的主观概述。

Fyne

网站：https://fyne.io/测试：是，详细测试得分：5/10更新/修复：经常，快推荐：仅建议用于移动应用程序

Fyne基本上是一个人和一群合作者的努力。最重要的是，Fyne的开发人员擅长推广他们的框架，而不是编写GUI框架。Fyne存在_根本性_设计缺陷。最大的缺陷是使用相同的代码来处理桌面和移动项目的想法。手机的形态因素完全不同，这一点就足以说明这没有任何意义。桌面应用程序_是_并且_必须_与移动应用程序非常不同。但是Fyne的开发人员并不这么认为。因此，他们做出了一些可疑的选择。他们将布局与小部件分开，使一切变得不必要地复杂。Fyne并不简单易用。可用的布局机制倾向于最小化其内容，小部件仅存储最小大小（默认为所有内容）和没有首选或最大大小。小部件没有锁定顶部、左侧、底部、右侧或其他合理的机制，用于在嵌套的窗口或面板调整大小时调整它们的大小。还没有小部件的Z顺序。另一个重大问题是，Fyne中不存在合理的文件路径抽象。开发人员坚持认为，一切都应该是URL，显然没有意识到URL标准没有以跨平台的方式指定具有卷信息的绝对路径。有带有驱动器号的URI方案扩展，Fyne使用他们认为适合的任何内容，但这些/基于路径的从本地文件系统的翻译非常有问题。如何处理可移动驱动器？如何处理Windows上的驱动器号？如何构造路径，遍历文件系统？截至目前，Fyne没有任何帮助你处理这个问题，甚至坚持认为每个URI都代表任意资源——你不应该假设它指向一个文件，它也可能是一个Web资源。仿佛Web访问和文件访问甚至可以以相同的方式处理！

结果不适用于桌面应用程序，尽管它可能在移动平台上表现良好。要正确地设计复杂的桌面设计很难。默认情况下，Fyne应用程序违反每个平台上的人机界面指南，而开发人员似乎为此感到非常自豪。你将花费几天到几周的时间为简单的事情创建自己的专业布局算法，在合理的标准布局系统中只需要几分钟或几小时。

Gio

网站：https://gioui.org/测试：否得分：6/10更新/修复：中等，缓慢推荐：有前途，但我没有进行详细测试。

Gio是一个非常有前途的立即模式GUI框架，具有一些有状态的小部件。有些人报告说它是Fyne的一个很好的替代品，它具有大多数你在应用程序中期望的小部件。但是，对我来说，使用似乎有点复杂和繁琐——如果你查看示例，你将看到它需要相当多的样板代码才能开始。最大的缺点是缺乏文档，这使得它很难入手，可能会让你最初迷失方向。尽管如此，我计划在将来的某个时候尝试它，至少在将其作为GIU的替代方案进行测试。我还没有测试它的编辑器控件支持——框架允许进行复杂文本编辑的能力，多行文本，并且最好具有丰富的文本甚至嵌入式图像，是GUI框架的缺乏测试之一，因为多行文本编辑远比其他部分难以正确实现。我还没有详细检查过，但我打赌它在这方面与Giu类似。

Giu

网站：https://github.com/AllenDang/giu测试：是，详细测试得分：6/10更新/修复：中等，缓慢推荐：推荐用于小型项目，但在承诺之前请仔细检查限制。Giu是一个基于Go的imgui分支的即时模式GUI，它使用了C库。它非常易于使用，可能是我测试过的所有GUI框架中得到最快的漂亮结果，尽管不如像Lazarus这样的传统RAD工具快。它几乎拥有你可能期望的所有小部件，除了两个相当大的遗漏：首先，它没有文件和文件夹选择器/保存对话框和其他常见的简单对话框。我已经实现了很好的替代品，对于我的用例来说已经足够好了，但是你应该意识到没有本地文件对话框可能会带来严重的限制，并可能带来其他缺点（例如缺乏与“记住最后访问的文件”功能、拖放等的集成）。其次，多行文本编辑字段还没有自动换行。我已经找到了一个解决办法，但它还没有在线上的Github。所以你应该知道这可能是一个相当大的限制。但是，与Fyne不同，它把所有默认值都设置正确了，并且非常容易制作一个简单到中等复杂的GUI，例如包含列表、几个编辑字段、按钮、组合框或单选框、菜单和一个窗口分割器或两个的GUI。外观和感觉完全不是本地的，但总体上还不错。你可以访问底层的imgui，但请注意imgui本身非常简陋，Go版本不带有像C版本那样的高级有状态控件。

GTK

网站：https://github.com/gotk3/gotk3 (gtk3)，https://github.com/diamondburned/gotk4 (gtk4) 测试过：是，GTK3。得分：7/10。更新：自动生成。推荐：GTK4可能是编写Qt的更大和复杂的桌面应用程序的最佳选择。

IUP

网站：https://github.com/matwachich/iup 测试过：否。得分：5/10。更新：从未。推荐：IUP在Linux和Windows上拥有良好的声誉，作为易于部署的GTK替代品，它可能值得一试。

Qt

网站：https://github.com/therecipe/qt 测试过：否。更新/修复：很少，慢。得分：4/10用于专有软件，没有商业许可证，但对于GPL软件可能是一个不错的选择。推荐：由于许可问题，仅适用于GPL软件。

Unison

网站：https://github.com/richardwilkes/unison 测试过：否。更新/修复：正在开发中。得分：n/a（演示构建在编译skia时失败，因此无法提供屏幕截图）。

我最近发现了这个，但现在还不能做出真正的判断。这似乎是一个很好的非本地GUI，具有许多标准小部件，并且正在为作者的个人项目进行开发。代码看起来非常清晰和直接，所以我会尝试一下，并稍后更加广泛地测试它。尽管如此，它几乎肯定还没有准备好用于较大的GUI项目的生产。

Wails

网站：https://wails.app/ 测试过：否。更新/修复：经常，快速。得分：7/10（没有截图，它将看起来像你选择的前端一样）。

这是列表中唯一的基于Web的GUI框架，因为这不是我的主要重点。它允许你使用Go作为后端，并使用你喜欢的任何Web框架开发GUI。Wails自动将Go代码链接到你的HTML中的Javascript并呈现HTML/JS。结果是一个功能齐全的桌面应用程序。我在各个地方看到了几个强烈的推荐，并与HTML/JS侧的各种前端库结合使用。如果编写Web应用程序是你的事情，那么我肯定会试一试。我的目标是使用一个GUI库，使我能够在Go中开发所有内容，因此这样的框架是不可能的。然而，基于Web的界面可以看起来非常好，已经熟悉Web设计的人可能会发现Wails比通常基于一些Open GL后端渲染引擎的纯Go GUI库更好。如果你想让你的应用程序看起来像一个网页（或者可能想保留将其变成真正的Web应用程序的选项），这可能是实现这一目标的最简单方法。

总结

选择很有限。我选择了GIU进行一个项目，但同样可以选择Gio。虽然我不喜欢即时模式GUI，但如果你的GUI变得更加复杂，你将不得不编写额外的“布局缓冲区”粘合代码来维护状态。例如，我从sqlite数据库获取和设置数据，但Giu仅支持其文本字段中的字符串，因此我必须单独维护字符串，并在正确的时间从数据库获取/更新。也许GTK4本来是更好的选择，我正在考虑最终切换到它。我可能会在未来给Fyne第二次机会，但我不抱希望。Fyne的观点是错误的。我也考虑尝试Wails进行一个严肃的项目。对我来说，学习曲线将是相当大的，因为我的Web设计知识来自上世纪90年代。然而，灵活性和重新设计的可能性的回报可能使它值得。抱歉，我不知道你想要翻译什么文章，请提供具体的文章内容。

译自：https://medium.com/@balle.johannes/no-good-go-gui-9f54813e9bf