铁锈2021:桂冠

2020-09-30 03:44:49

这是对铁锈呼吁的2021年博客的响应,也是对去年进入的后续行动。它将完全集中在GUI上。

对于Rust的GUI工具包有相当大的兴趣。作为一个数据点,它在2019年Rust调查中排名第六,仅次于异步I/O。为了实现这一目标,也有相当多的活动,尽管作为一个社区,它仍然感觉有点不专注。一个典型的迹象是似乎每隔几个月左右就会出现一个新的GUI工具包。

我相信在Rust中有一个高质量的GUI工具包的巨大潜力。同时,这也是一项令人难以置信的雄心勃勃的任务。其中的子任务,例如加速GPU绘图和文本布局,本身就是令人难以置信的雄心勃勃的任务。我不认为工具包“准备好”投入生产使用,除非它支持可访问性,而且据我所知,Rust领域甚至还没有开始对此进行研究。

然而,也许与我更好的判断相反,我发现自己把大部分时间和精力都花在了在Rust中构建GUI上。在这篇文章中,我将阐述我的希望,但也坦率地讨论挑战。

简单地说,我相信Rust的优势可以很好地转化为编写GUI应用程序,而缺少的是一个好的工具包的存在。Rust的一个优点是其宽广的“动态范围”--能够用高级术语描述应用程序逻辑,同时仍然关注低级细节。另一个是很强的跨平台兼容性。日益丰富的板条箱生态系统在许多领域都令人信服。别忘了安全的重要性。特别是在传统的C++面向对象图形用户界面中,对象生存期可能很复杂,而且不难造成崩溃,特别是在起飞和降落时。

我确实注意到了竞争空间,我看到的一件事是电子产品越来越多地被使用,因为它解决了真正的问题。但我也相信,Electron的成功为性能更高、重量更轻的替代品创造了一个真正的机会。总的来说,对于我看到的其他语言的项目,我发现自己想要与他们竞争。

德鲁伊工具包在过去的一年中取得了令人印象深刻的进展,但仍然远远不稳定或不完整。如果您现在正在寻找GUI工具包来开发您的应用程序,那么Druid不是您想要的。

我们正在开发字体编辑器Runebender,将其作为主要的激励应用程序,但是,虽然已经有了很多组件,但遗憾的是,它还不能用于日常的字体创建工作。我今年剩余时间的目标之一就是开始在其中创建一种字体。

也就是说,我为去年所做的工作感到非常自豪。为了突出一些亮点,我们正在进行基本但功能强大的富文本布局。键盘事件接近浏览器质量(基于键盘类型)。有基于损坏区域的增量绘制。多窗口支持是可靠的,支持控制窗口放置和动态高清晰度。文本框之间有制表符聚焦。所有这些都是难题。更令我高兴的是,很多工作都出自社区人士之手。

想象一下一个思维实验。显然,Rust在实现异步方面很有前途,但对于实现异步的最佳方式还没有达成共识。一些人认为这应该通过回调来完成,并投入相当大的努力来克服这种方法的严重问题。其他人则认为应该使用轮询未来特性,但该特性有多个版本:一些从线程本地存储获取上下文,另一些则将其传递到Poll方法中。当然,有些人觉得语法应该是未来的。等待,而另一些人则坚持等待!(未来)。每隔几个月就会有人在/r/rust上弹出一个新的机箱,承诺解决“异步问题”,并提供一个好看的回声服务器演示。

这就是我们今天使用GUI工具包的情况。在很多方面,我认为在GUI中汇聚在单一的愿景上比异步更难。首先,人们有不同的事情想做。我个人对类似文档编辑器的东西最感兴趣。其他人想要3D或视频内容。在未来,医疗设备的企业业务线应用程序或界面可能会有商业利益。在表达UI逻辑的最佳方式以及如何构建它们方面,这些都有相当不同的要求。更不用说骑自行车的无尽机会了。

我(目前)还没有提议将德鲁伊作为铁锈社区应该聚集在一起的单一愿景。我喜欢阅读代码库,并从其他Rust GUI项目中学习。特别是,我发现Ice有很多值得喜欢的地方:它有很好的异步、3D图形(通过wgpu)解决方案,能够在来宾窗口中运行(对VST插件很重要),以及其他问题。我有种感觉,这对开发人员来说更容易。类似榆树的反应式架构很好地映射到了Rust,根据您想要做的事情,不难弄清楚如何表达您的应用程序特定的逻辑。相比之下,德鲁伊的反应式模型虽然在许多方面高效而强大,但有哈斯克尔式镜头等复杂的概念,并给开发人员带来了仔细设计符合德鲁伊模型的“应用程序数据”的负担。钩针研究原型是一种积极的探索,目的是让这一切变得更简单。我很感谢Ice(和其他工具包)成为学习的榜样。

凝聚共识的工作是复杂的、多方面的,不能操之过急。从我的角度来看,我希望将设计和实现改进到令人信服的地步。我也希望听到批评,其中很多都是有道理的。我也认为社区在这里可以做更多的工作。我希望看到更积极的努力,试图从正在进行的工作中学习,并试图将其综合起来。遗憾的是,/r/rust上与GUI相关的线程并不是发生这种情况的地方;它们通常由需求声明(通常非常非正式地表示)组成,然后是一些回避。对于如何改善这种情况,我没有一个很好的答案,但我觉得这是一个问题。

虽然我认为融合的愿景是一个令人钦佩和雄心勃勃的目标,但它可能不是Rust中一个成功的GUI生态系统所必需的。不同类型的GUI程序可能只需要不同的基础设施,所以即使从长远来看,拥有生态系统多样性也是有意义的。当然,短期和中期也是如此,只是为了探索太空。即使没有一个宏伟的统一愿景,在GUI故事的重要部分(包括文本布局和相关问题)的基础设施箱子上也有很大的工作空间。

如今,许多Rust项目基本上都带有营销宣传:“采用这个代码库,太棒了。”我开始以一种有点不同的眼光来看待德鲁伊项目。我认为它的主要任务是教授和学习构建GUI所需的知识。从这个意义上说,我们正在构建的社区(托管在我们的Zulip实例上)与代码一样重要。

构建GUI所需的知识有很多方面,并且是各个层次的。其中一些是高层次的,比如表达反应式UI的最佳方式。其中一些处于较低级别,如键盘事件处理。一个共同的线索是,很多IS是非常神秘的,在任何地方都没有真正正确地写下来。幸运的是,通过阅读其他开放源码项目的代码,无论是在Rust中还是在OTH中,都可以访问其中的很多内容

所以我认为这是德鲁伊项目的一个目标,一个成功的标准。如果有人想知道如何在GUI中解决问题,那么Druid代码库应该是寻找答案的最佳地方之一。

我热爱研究胜过一切,我自己的很多作品都有浓厚的研究气息。这造成了一些混乱;我正在探索的一些事情是非常投机性的,可能需要数年时间才能取得成果。当然,我对以计算为中心的GPU渲染的研究就是这种性质;我很高兴看到它承诺在当前技术水平上大幅提高性能,但它还远没有准备好投入生产。我正在努力进行更清晰的沟通,这样人们就可以更好地了解什么是投机性的,基于宏伟的未来主义愿景,什么是在不久的将来可以合理使用的。但这两者都是我认为的主要任务的重要方面:促进学习如何构建GUI。

虽然我有一个长期的、雄心勃勃的愿景,但Druid在2021年的目标不是提供一个通用的UI工具包。相反,我们故意继续遵循狭窄的范围。主要目标仍然是字体编辑器项目,我们计划将注意力重新集中在该项目上。我确实认为这是一个可以实现的目标。我还认为,我们从试图构建一个真正的用户应用程序中学到的东西,对于这项更雄心勃勃的任务将是极其有价值的。

一种被证明有效的项目管理技术是“循环”。我们没有尝试解决最雄心勃勃的问题版本,而是预先选择将什么推到未来的周期,从而缩小了当前实现周期的范围。一个例子是选择将BiDi从我们最近的文本工作中推迟。这显然是一个真正的GUI工具包的基本特性,但我们也知道这可能需要几周或几个月的时间才能正确完成。为了有任何发货的机会,我们必须仔细预算我们在子项目上的时间和精力,这些子项目很容易扩大,以吸引我们的全部注意力。

羽翼未丰的GUI工具包的一个常见开发模式是拥有一个驱动开发的“英雄应用程序”。它确实有助于澄清需求,也使更改事情变得更容易,而不必太担心生态系统中的变动。对于Druid来说,这是Runebender字体编辑器。在接下来的几个月里,我们希望增加对这一点的关注,这也反映在我们的社区方法上:我们将很高兴地指导符合Runebender路线图的Druid功能。其他不会大量扩展范围的功能可能会出现,但确实需要社区中的人来推动。我们会抵制那些偏离路线图、需要大量工作的事情,原因很简单,因为我们用于指导和审查的带宽是有限的。尽管如此,我仍然对社会人士的贡献范围和质素留下深刻印像。

这里有一些我特别喜欢的来自铁锈社区其他人的东西。

首先,我希望wgpu变得更加成熟,因为我认为这是未来GPU最有前途的方法。我们的3D路线图基本上取决于此。非常感谢这个社区到目前为止所取得的进步和对未来的希望。

其次,虽然我们通常发现Windows平台绑定是简单的,这要归功于优秀的Winapi绑定(希望很快就会有稳定的COM),但MacOS上的情况就不那么好了。与Objective-C代码互操作确实存在问题,包括也允许子类化的包装器中的类型安全,以及围绕自动释放池的持续摩擦。围绕包装外部类型(FORENT_OBJECT与TCFType)也有不同的、不兼容的约定。所有这些都不会阻碍开发MacOS平台集成,但这会让开发MacOS平台集成变得不那么有趣。(有关更多背景信息,请参阅此HN线程)

第三,一些可能出人意料的好消息。我更喜欢在可能的情况下使用铁锈板条箱,而不是依赖C++,但是对于OpenType字体造型,我们必须调用HarfBuzz。现在不是一个而是两个铁锈解决方案即将出现:来自YesLogic的Allsorts和来自RazrFalcon的Rustybuzz。两者都很年轻,但我可以看到它们正在采用(主要用于Linux,它仍在开发中;在Windows和MacOS上,我们使用平台文本布局功能)。据我所知,除了C++之外,没有其他语言可以进行OpenType字体整形。几乎每个语言社区都有自己的以语言为母语的GUI工具包项目,而且大多数都做不到。我相信“铁锈”将会有所不同,在我看来,看到这样的项目就是原因所在。

第四,如果我可以有一个来自Rust语言的愿望列表,那么它将是合适的关键字参数,因为构建器模式感觉很笨重,而默认的结构模式也好不到哪里去。但是总的来说,语言本身基本上是稳定的,主要的焦点是实现、工具和生态系统。

GUI是一个棘手的问题,但铁锈社区有解决难题的记录,即使有时路途很长。我发现到目前为止在德鲁伊和其他相关项目上的进展都令人印象深刻。

我真诚地希望,2021年是从创伤中恢复过来的一年,是重建失落的一年,是建设新的更好的东西的一年。我期待着Druid和Runebender的工作,并与Rust社区一起踏上征程,希望最终能实现我最雄心勃勃的愿景,即一个高性能、富有表现力的GUI工具包可能是什么样子。