如何从零开始写Golang的GUI框架？

创建于 2022 年 5 月 14 日星期六

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

我调查的底线是 Go 还没有任何好的 GUI 选项。这是不幸的，因为否则 Go 将成为易于使用的快速应用程序开发的完美替代品，就像我以前使用 REALBasic 时那样——现在被称为昂贵得令人望而却步的 Xojo。到目前为止，没有任何框架或语言 + IDE + 框架组合能够超过我使用 REALbasic 所体验到的生产力。我尝试过Lazarus，但 Object Pascal 不是一个很好的替代品，该语言只是显示了它的年龄，并且有时不得不手动管理内存对于桌面 GUI 应用程序有很多缺点。我本可以从我喜欢和熟悉的语言中选择另一种语言。球拍有一个非常完整的图形用户界面。多年来，我一直在其中编写和维护 GUI 应用程序。但是，我已经放弃了它，因为其中的 GUI 应用程序会感觉迟缓，而且应用程序启动时间使 Racket 成为“活泼”的小型 GUI 应用程序的次优选择。Ada感觉就像您将时间投入到技术债务中，并且缺乏第三方支持。GTK3是唯一一个不错的 GUI 选项。尽管多年来我一次又一次地尝试CommonLisp ，但它仍然感觉很老套，而且我发现它可用的第 3 方库缺乏文档和真实性。至于Rust，我已经学会了，阅读Klabnik & Nichols 的书从头到尾，我不得不承认我发现 Rust 没有吸引力并且过度设计。它对高完整性系统的可用性是值得怀疑的——为此我仍然推荐Ada/Spark——它对 GUI 编程没有任何优势，并且有一个整体有毒的社区。

所以最终 Go 被选择用于一个更大的项目，并且必须做出一些 GUI 库的选择。这是截至 2022 年 5 月的 Go GUI 框架的固执概述。

法恩

网站：https
://http://fyne.io/测试：是的，广泛。
得分：5/10
更新/修复：经常、快速
推荐：仅推荐用于移动应用程序

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

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

焦

网站：https
://http://gioui.org/测试：否。
得分：6/10
更新/修复：中等，慢
建议：有希望，但我没有详细测试过。

Gio 是一个非常有前途的即时模式 GUI 框架，也带有一些有状态的小部件。有人报告说它是 Fyne 的一个很好的替代品，并且它具有您在应用程序中所期望的大多数小部件。对我来说，这种用法似乎有点复杂和麻烦——如果你看一下这些例子，你会发现它甚至需要大量的样板代码才能开始。然而，最大的缺点是缺乏文档，这使得入门很困难，并且可能会让你一开始就迷失方向。不过，我计划在未来的某个时候试一试，至少是为了测试它作为 GIU 的替代品。我还没有测试它的编辑器控制支持——框架允许复杂文本编辑、多行以及理想情况下富文本甚至嵌入图像的能力，是 GUI 框架缺乏测试之一，因为多行文本编辑是迄今为止最难正确实现的。我没有详细检查，但我打赌它会与 Giu 类似。

朱

网站：https
://http://github.com/AllenDang/giu测试：是的，广泛。
得分：6/10
更新/修复：中等，缓慢
建议：推荐用于小型项目，但在提交前仔细检查限制。

Giu 是一种鲜为人知的即时模式 GIU，它基于 imgui for Go 的一个分支，它使用 C 库。它非常易于使用，可能是我测试过的所有 GUI 框架中速度最快的一个好看的结果，虽然不如 Lazarus 等传统 RAD 工具快。除了两个相当大的遗漏之外，它几乎具有您可能期望的所有小部件：首先，它没有文件和文件夹选择器/保存对话框以及其他常见的简单对话框。我已经设法实现了对我的用例来说足够好的替换，但是您应该知道，没有本机文件对话框可能会造成严重的限制，并且可能会带来其他缺点（例如，缺少与“记住最后一个文件”的集成）访问”功能、拖放等）。其次，多行文本编辑字段还没有自动换行。我已经找到了解决方法，但它还没有在 Github 上在线。所以你应该意识到这可能是一个非常严重的限制。然而，与 Fyne 不同的是，它的所有默认设置都是正确的，并且很容易用它制作一个简单到中等复杂的 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
://http://github.com/matwachich/iup已测试：否。
得分：5/10
更新：从不
推荐：IUP 在 Linux 和 Windows 方面享有盛誉，作为 GTK 的替代品可能值得一试更容易部署。

Qt

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

齐声

网站：https
://http://github.com/richardwilkes/unison已测试：无
更新/修复：正在开发中
分数：n/a
[编译skia时演示构建失败，因此没有截图可用]

我最近发现了这一点，还不能真正判断这一点。这似乎是一个不错的非本地 GUI，带有许多标准小部件，并且正在为作者的个人项目开发。代码看起来非常清晰和直接，所以我会尝试一下，稍后会更广泛地测试它。不过，几乎可以肯定它还没有准备好生产更大的 GUI 项目。

哀号

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

这是列表中唯一基于 Web 的 GUI 框架，因为这不是我的主要优先事项。它允许您使用 Go 作为后端，并使用您喜欢的任何 Web 框架为其开发 GUI。Wails 自动将 Go 代码与 HTML 中的 Javascript 链接并呈现 HTML/JS。结果是一个成熟的桌面应用程序。我已经在不同的地方看到了一些强烈的建议，并结合了 HTML/JS 端的各种前端库。如果无论如何编写 Web 应用程序是你的事，我肯定会尝试一下。我的目标是使用一个允许我在 Go 中开发所有东西的 GUI 库，因此这样的框架是不可能的。但是，基于 Web 的界面看起来非常好，并且已经熟悉 Web 设计的人可能会发现 Wails 是比任何非本地界面更好的选择，Go-only GUI 库，通常基于一些 Open GL 后端渲染引擎。如果您希望您的应用程序看起来像一个网页（或者可能希望保留使其成为真正的网络应用程序的选项），这可能是实现这一目标的最简单方法。

概括

选项是有限的。我为一个项目选择了 GIU，但也可以选择 Gio。不过，我不能说我喜欢即时模式 GUI。如果您的 GUI 变得越来越复杂，您最终将编写额外的“布局缓冲区”胶水代码来维护状态。例如，我从 sqlite 数据库获取和设置数据，但 Giu 仅支持其文本字段中的字符串，因此我必须单独维护字符串并在正确的时间从数据库获取/更新。也许 GTK4 会是更好的选择，我正在考虑最终切换到它。未来我也可能会给Fyne第二次机会，但我的希望并不高。Fyne固执己见，但方向错误。我也在考虑为一个严肃的项目尝试Wails。对我来说，学习曲线会很长，因为我的网页设计知识来自 90 年代后期。然而，