|
最近，我一直在试用Godot Game Engine，而我所看到的一切给我留下了深刻的印象。 尽管它被设计用于制作游戏，但它具有用于制作图形用户界面的极其复杂的系统。 我认为这是高级GUI应用程序的未来。 不服气吗？ 看下面的图片。 这来自Godot编辑器。 看起来很精致吧？ 你得到了： · 节点的画布连接了可视化编程系统中使用的节点（除其他几个受支持的编程系统之外）。 · 资源管理。 · 一个复杂的树小部件，用于处理场景图。 · 具有可以过滤的属性的检查器。 · 具有语法高亮显示，高级代码完成，跳转到定义，实时警告等的代码编辑器。 · 瓷砖地图编辑器，动画编辑器以及许多其他音频编辑器，还有许多我还没有时间探索的东西。 > The Godot editor is a sophisticated GUI application made in Godot itself. 您如何看待他们制作了如此复杂的GUI？ 是Qt吗？ Coco？ 不，所有这些都是由Godot Game Engine本身完成的。 他们真的在吃自己的狗食。 因此，您在这里看到的所有内容都可以使用Godot在自己的应用程序中完成。 当然，您可以通过其他工具找到复杂的GUI。 例如。 一些竞争引擎使用Qt进行编辑。 小小的但是这里是踢腿： 所有带有引擎端编辑器的Godot都只有31.1 MB下载。 一键安装，编辑器立即启动。 当我打开包装并安装时，它仍然只有70 MB。 相对于您获得的功能而言，这绝对是个很小的安装。 让我们对此进行一些介绍。 仅下载Qt5，需要5 GB的可用空间！ 考虑一下Qt Creator IDE，它非常简单，没有需要运行的Qt，它需要200 MB以上的内存。 Xcode呢？ 下载超过5 GB。 安装后，它在我的硬盘上大约需要10 GB。 那是一个完全不同的联盟。 Android Studio为500 MB，Android SDK为1.5 GB。 尽管尚不清楚它们是否比Godot提供更多的功能，但这些功能还是很大的。 仅用于演示内容的主题演讲有433.5 MB。 它可能会排除共享框架。 让我们看一下Godot在大小上与哪种应用相比。 1已安装用于管理密码的密码55.5 MB。 非常接近戈多。 邮件约为30 MB，照片约为50 MB。 换句话说，Godot的大小非常接近具有非常狭窄的功能集的应用程序。 使用起来很爆炸与我以前使用过的相比，Godot GUI设计的工作速度非常快。 他们在构建UI时确实考虑了许多常见问题。 您将GUI建筑围绕以下所示的场景树居中。 > Add, duplicate and rename GUI components with keyboard. 您可以使用键盘在该树上上下移动。 所以我可以 使用箭头键移至要向其添加GUI组件的容器或面板。 然后，我可以按Cmd + A（在Mac上）以打开一个对话框来选择GUI组件。 您会弹出下面的对话框。 > Correct GUI component is quickly located with filtering. 现在，您可以使用鼠标展开一棵大树，显示成吨的节点。 但是非常有效的是，当对话框打开时，您将立即进入搜索栏。 我可以开始输入'按钮'来查看存在类似节点的按钮。 当我输入内容时，列表会被过滤。 在发生这种情况时，我可以同时用箭头键移入列表进行选择。 即使这样做，我也不会错过对搜索栏的关注。 因此，我可以选择所需的节点，然后按Enter。 它作为子级添加到我先前选择的节点中。 这样，我完全将键盘与箭头键，Cmd + A和Enter结合使用来构建GUI。 如果我按下某个组件上的Enter键，则可以更改其名称。 如果我按Cmd + D，则将其复制。 因此，我不需要多次打开并搜索标签。 如果我知道我需要10个标签。 我可以做一个标签，然后重复10次。 Sane UI组件选择但是，使用该系统的效率并不止于此。 在各种UI设计工具中，对我来说最令人沮丧的事情之一就是选择由多个其他组件组成的UI组件。 例如。 在Qt Creator中，我经常会尝试选择一个包含子组件的布局，而只是意外地选择了一个子组件并将其拉出布局。 在Godot中，意外选择子组件不是问题。 请注意，我在下面的MarginContainer旁边用粉红色圈出的小图标。 之所以切换此图标，是因为我早先单击了工具栏中的黄色圆圈图标。 这样可以避免在画布上选择孩子。 我仍然可以在树中选择它们，但是如果单击布局正确的组件，则会得到父项。 > Blocking child nodes from getting selected by accident. 这确实很实用，因为它可以轻松处理布局。 在其他编辑器中，选择布局可能很棘手。 戈多的另一个重要细节。 您无需在画布上更改父级关系，仅在节点树中即可。 因此，您不会意外地从层次结构中提取组件。 在这种情况下，您要做的就是将子组件相对于其父组件的相对位置更改。 UI组件的高级定制在任何高级GUI中，您将需要以特殊方式配置的许多特殊的自定义GUI组件，以适合您的应用程序。 这对传统的GUI设计人员来说从来都不是一件好事。 您可能可以对组件进行子类化，但通常它只会在GUI编辑器中显示为灰色矩形。 而且，如果确实显示，则不能对其进行太多配置。 一切通常都必须用代码完成。 Godot并非如此。 在下图中，您可以看到我们已将脚本附加到名为ColorPicker的节点上，该脚本的类型为OptionButton。 将脚本附加到Godot中的节点等同于对该节点进行子类化。 这就是为什么您可以看到脚本代码说扩展OptionButton的原因。 OptionButton是一个下拉菜单。 开箱即用Godot在GUI中没有任何机制可以指定应包含的元素。 但是，我们可以将自己的属性添加到Godot编辑器的任何场景节点对象的检查器中。 您会在突出显示中看到我已编写以下代码行： export(Array, String) var itemvalues = ['red', 'green', 'blue'] 这告诉Godot成员变量itemvalues应该在Godot编辑器中可见。 我也告诉它这是一个带有String元素的数组。 GDScript使用的语言是动态键入的，因此它们更像提示。 这样的结果是，您可以看到选择了ColorPicker时，检查器将显示itemvalues的条目，我可以在其中修改元素。 您可以看到在此示例中，我将最后一个值从' blue'更改为' cyan' 组件已加载到场景中并准备使用时，将调用_ready函数。 在这种情况下，我们利用机会来读取用户将itemvalue设置为什么，并将每个条目添加到下拉菜单框中。 聪明并不止于此。 如果我复制此组件并在其他地方使用它，则将使用相同的附加脚本。 如果我更改一个组件上的代码，它将更改所有其他组件上的代码。 因此，它们不会轻易脱离同步。 如果我确实想要自定义行为，则可以在特定组件上分离脚本。 或者，我可以使用子类扩展它以改善行为。 编辑和修改正在运行的应用程序我可以继续讲其他几十个小细节，这使GUI编辑在Godot中变得轻而易举。 但我希望我能理解他们对人体工学的真正想法。 过去遇到的许多问题阻碍了我有效地使用他们似乎预料到的GUI。 但是，真正的杀手级功能可能是您可以在运行应用程序时运行其应用程序并修改其GUI布局和附加脚本的代码，并且这些更改会立即反映在正在运行的应用程序中。 确保可以在运行时编辑代码的这种功能以某种形式存在于许多地方。 但是，如果您的经历像我的一样，那么您就会知道，如果您使用编译语言，那么这些东西通常会很脆弱并且很有限。 Godot使用一种动态语言，该动态语言具有称为GDScript的Python语法，该语言专门为与编辑器集成而设计。 这意味着它旨在处理重新加载和同步。 而且您可以说它确实运行良好。 这是一种非常容易学习的语言。 我基本上是在一天之内捡起来的。 它与发动机的集成度非常好。 您可以命令单击任何内容以跳至其定义文档。 您可以很好地完成命令。 即使它不是真正的静态类型语言，它在弄清楚类型方面也非常出色。 就像现代Python一样，您可以在任何想要改善猜测的地方添加类型提示。 它不仅完成类型名称和函数名称。 当您在场景图中写入到节点的路径时，它甚至会完成字符串。 那比赛呢？当然，替代方法是使用诸如Electron，Qt Widgets，Qt QML或Cocoa之类的东西。 替代方案的第一个问题是它们是巨大的肿的笨拙野兽。 如果有人想查看您正在使用的GUI，可以考虑一下，您可以将它们发送给Godot项目文件，并且距离他们31 MB的下载距离。 哦，我是否告诉过您，Godot是完全免费的开放源代码，并获得了MIT的许可？ 没错，任何人都可以免费下载它，并通过Godot进行任何所需的操作。 Qt小部件尝试让别人看看您制作的Qt设计。 '糟糕，您需要5 GB的下载量才能做到这一点。 哦，顺便说一句，您需要在网站上注册一个帐户，登录和搜索真的很难找到免费版本。' > Screenshot of Qt Creator in action designing a GUI using desktop widgets. 更不用说，如果您使用的Qt Widgets应该用于大型专业GUI应用程序，这是我在这里讨论的主题，那么您必须使用坦率地说很糟糕的GUI设计器。 实际上，这就是为什么我制作了自己的标记语言ERML的原因，只是为了允许对Qt ui文件（而非Qt Creator的GUI）进行更合理的编辑。 Qt Creator为什么会吸引您的要求？ 本文提到的许多事情。 选择和使用组件的嵌套布局几乎是不可能的。 而且对象树结构无法让您做任何有用的事情。 它基本上是一个'只写'系统。 您可以使复杂的GUI相当好，但是祝您稍后运回并进行重大修改。 您将看到布局的喙，并且您将不记得如何将其放回原来的状态。 而且，没有一种合理的方法来定义要在编辑器中使用的自定义组件。 在Godot中，这很简单。 您可以制作由其他组件组成的任意复杂组件，并轻松地重用它们。 当然，您可以在Qt Creator中复制粘贴GUI组件的集合，但是如果您决定要进行修改，就很麻烦。 相反，在Godot中，您可以使用作为模板制作的GUI组件的集合。 也基于该模板更改来更改模板和所有其他GUI组件。 更不用说您不能更改用户界面的生活。 Qt C ++项目很容易获得很慢的周转时间，这在制作GUI时完全丧失了生产力。 Qt QML救援了吗？那么QML呢？ 它解决了许多问题，并利用动态语言简化了动态更改类型。 老实说，我不记得QML的工作细节。 我只记得它不像我希望的那样直观。 编辑器花了我很多时间来缠住我的头，它真的一点也没有磨光。 很多东西感觉很慢。 我制作的GUI效果不佳。 当我调整窗口大小时，即使是相当简单的东西也很难重绘。 也许因为它是为移动设备设计的，因此并未针对更改尺寸的窗口进行优化？ 我不知道。 尽管进行了各种测试，但我在绘图中无法获得令人满意的性能。 但是，最大的杀手可能是没有全面的高级小部件来构建高级GUI应用程序。 Coco和SwiftUI在Swift中使用Xcode的iOS应用程序时，我已经使用基于约束系统的布局管理器。 这是一个非常强大和先进的系统。 起初，我认为这确实是前进的道路。 但是根据我的经验，它太复杂了，无法使用。 即使对于简单的屏幕，有时我也遇到了非常复杂的约束，很难调试。 虽然我在Xcode和Swift上花费了很多时间，但也许对它的效果的最终测试是在离开Xcode和Swift一段时间后，又花了多少时间重新进入它。 这对我来说效果不佳。 我无法理解过去所做的很多事情。 斯威夫特变得太复杂了。 这是一种不错的语言，但是具有讽刺意味的是，它正在开发一些与C ++和Haskell相同的问题。 类型系统的复杂性和严格性经常出现在您的面前。 这是一把双刃剑。 当我开始使用Swift时，我很喜欢强类型键入如何捕获许多错误。 但这总是让人感到mixed贬不一，因为与类型系统作斗争是经常发生的事情。 现在似乎情况变得越来越糟，尤其是在处理闭包时。 整个设置很容易给您带来精神负担。 我无法有效地使用该系统，因为我根本无法将您需要了解的所有内容都保存在脑海中。 SwiftUI似乎是一个有前途的选择。 它遵循与QML相同的方法。 我认为这是一个很有前途的模型。 我并不反对QML，因为我认为这不是一个好主意，只是因为我认为它执行得不好。 我只简单地使用过SwiftUI。 对我来说，这似乎是一个明显的改进，但恕我直言，它仍然不及Godot。 当您获得GUI组件的GUI检查器面板时，仍然不得不在很大程度上用代码编写GUI。 我认为GUI编辑应该同时支持两者。 GUI设计是非常直观的过程恕我直言。 也许更重要的是，仍然没有能力对正在运行的应用程序进行实时更改和修改。 对于具有大型项目的复杂GUI应用程序，在您要进行测试之前必须先对其进行加载，这是一个杀手kill。 HTML5，CSS和JavaScript我对Web技术的讨论需要一些免责声明。 我对网络技术的经验很少，而且我不太喜欢网络技术。 我是一个老派的GUI工具包人，他在旧的Amiga 1000上使用Intuition工具包进行了他的第一个GUI工作。 > This is where my GUI programming started, on an Amiga 1000 running Workbench 我仍然必须承认，我喜欢Web技术的许多方面。 在浏览器中，您可以实时编辑和更改属性，还可以立即查看对GUI的更改。 但是，我看到几个非常大的问题： · 这真的很复杂。 我在学习现代HTML5，CSS和JavaScript框架方面的个人经验需要花费大量时间。 我试图概述不同的Web技术以及它们之间的关系可能会给人一种感觉。 · 它是为网页而不是应用程序制作的。 当尝试为应用程序制作GUI时，我发现我经常遇到假设我们处于某个可滚动网页中而施加的限制。 · 它不是为可重用的组件（如真正的GUI工具包）而制造的。 后者需要一些解释。 创建可重用组件的Web方法是通过某种模板。 基本上，您只是几次复制粘贴一段HTML来代表新的自定义组件。 这意味着您通常在通过模板引擎进行工作，并且在编写的内容与Web浏览器中发生的事情之间没有一对一的映射。 这与例如Godot相反。 从开发的角度来看，我可以创建一个自定义组件并将其实例化。 当我在应用运行时进行实时修改时，这些事情是一回事。 在实时应用程序中，我得到了与编码时相同的节点。 这有助于整个往返行程，并降低了与此相关的心理复杂性。 现在，使用游戏引擎制作应用程序似乎有些疯狂，因为由于需要持续渲染，它确实窃取了更多的CPU周期。 但是，与基于资源的基于Web的应用程序相比，在许多方面它显得苍白无力。 VSCode和Atom之类的编辑器表明，可以使用网络技术来制作一些很棒的东西。 但是，我们也有像Insomniac Games这样的公司，他们尝试使用网络工具制作游戏引擎编辑器。 那主要是一次失败的实验。 他们看到的问题是，它的工作太糟糕，无法制作复杂的自定义GUI组件。 如今，大多数网络技术的使用都没有问题，因为它们不使用自定义组件。 原子例如 没有色轮的颜色选择。 为什么游戏引擎是未来？使用游戏引擎制作GUI应用程序似乎很疯狂。 人们可能会觉得这样做是本能的。 但我认为，世界有可能以这种方式结束，这有很好的理由。 这一切都与金钱在哪里以及激励作用有关。 游戏业是巨大的。 当今的游戏具有巨大的复杂性，可以与大多数实际应用程序匹敌。 游戏开发面临一些残酷的生存条件。 它们必须允许开发非常高性能的代码，从而压缩计算机的每一分性能。 他们必须在进行迭代的同时执行此操作，并且制作游戏时必须非常快速，轻松地进行实验。 游戏几乎就是定义，不是您可以预先明确定义的东西。 为了使游戏正确，需要进行大量的调整，实验和玩法。 这导致游戏引擎解决了我们那些在大型复杂GUI应用程序上工作的人们所面临的问题。 运行代码的实时修改在游戏引擎世界中是很正常的事情。 它一定要是。 每次要在特定级别尝试调整某项内容时，都无法重新加载整个该死的内容。 将此与引发问题的大量资金结合起来。 大型而复杂的GUI应用程序只是一个小众市场，游戏不是。 这就是为什么为机器人制作模拟器的人最终转而使用游戏引擎的原因。 引擎市场意味着游戏引擎在质量，性能和易用性方面远远超过机器人模拟器。 这种利用规模经济看似无关的怪异事物的方法并不是什么新事物。 例如。 特斯拉建立在这样一个想法上，即他们不使用定制汽车电池制造汽车，而是选择了使用7000笔记本电池为汽车供电的看似疯狂的想法。 看来这是一个荒谬的解决方案，但之所以奏效，是因为标有标记的笔记本电脑非常庞大，这使笔记本电脑的电池确实非常便宜。 这将通过传统的GUI工具箱来实现：它们将落后于竞争激烈的游戏引擎世界中正在发生的一切。 使用游戏引擎的关键缺点是不断渲染，这会导致较高的恒定GPU和CPU使用率。 尽管阅读本文的许多人反复向我指出，但Godot实际上确实具有低CPU使用率模式。 显然，仅当需要重新渲染对象时才渲染。 也许我们也可以吃一块蛋糕吗？ 我写了这个故事，认为Godot是解决大型复杂GUI的人们的挑战的答案。 但这也许实际上是每个人的解决方案。 据我所知，Godot引擎为解决方案增加了20–30 MB的开销。 对于中等大小的应用程序，可以接受。 似乎与我的日常编辑器TextMate相比，后者的大小为30 MB。 但是，与500-600 MB的Atom编辑器相比，实在是太便宜了。 那么，为什么要跳到Web技术上以获得跨平台的GUI应用程序呢？ 我们有一个Godot工具，它可以在所有主要平台上运行，它使用最少的资源，任何人都可以快速开始使用它。 简而言之，现实是网络技术广为人知，并将保持其主导地位。 但是，我认为对于大型复杂的GUI应用程序，我们一直渴望选择，而Web技术根本无法解决问题。 如果Godot要打入应用程序开发市场，他们可能必须像特斯拉那样做，从高性能跑车开始，然后逐步发展到日常用车。 现实世界的例子眼见为实。 不确定是否可以使用Godot进行真实的应用程序？ 看看这些家伙。 我们邀请了Alfred Reinold Baudisch，他很乐意分享他使用Godot制作Trello克隆的经验。 我们有安德鲁·沃尔德里奇（Andrew Wooldridge）撰写了有关在Godot中制作RSS阅读器的详尽指南。 而且我相信还有更多示例，但是我是Godot的初学者，并且没有完整的概述。 (本文翻译自Erik Engheim的文章《Is Making Advanced GUI Applications with Godot the Future?》，参考：https:///swlh/what-makes-godot-engine-great-for-advance-gui-applications-b1cfb941df3b) |
|
|
