Backstage

Fleet 后台探秘,第六部分 – UI 和 Noria

在本系列博文中,我们将以多个部分为您介绍构建 Fleet 这款由 JetBrains 打造的下一代 IDE。 第一部分 – 架构概述 第二部分 – 编辑器详解 第三部分 – 状态管理 第四部分 – 分布式事务 第五部分 – 代码补全的故事 第六部分 – UI 和 Noria 在本系列的第五部分中,我们讨论了 Fleet 的一项服务 – 代码补全。 现在,该谈谈我们自己的 JVM 声明式 UI 框架 Noria 了。 我们使用 Noria 构建了 Fleet。 来看看 Noria 背后的想法、主要概念和其他精彩功能。 一切开始的地方:Noria 窗口 UI 是如何构建的? 首先,我们有一台具备图形功能的显示器,它能够呈现应用程序的状态,也负责使我们的 UI 成为 GUI。 我们可能还有一个或多个输入设备,例如键盘、鼠标或触控板,用来传递命令和控制应用程序的行为。 在这些布置中,应用程序实际上是一个事件循环,负责回应用户和其他计算机系统组件(计时器、文件系统、网络等)发起的事件。 首先,回应是屏幕上显示的可见变化。 除了事件循环之外,GUI 应用程序通常还有某种窗口、其负责的屏幕区域以及该区域的一些绘图功能。 窗口通常由底层操作系统或它上面的窗口管理器提供。 操作系统可以提供图形 API 或将绘图委托给图形框架。 Fleet 既是 GUI 应用程序,也是 JVM 应用程序。 它可以

Fleet 后台探秘,第五部分 – 代码补全的故事

在本系列博文中,我们将以多个部分为您介绍构建 Fleet 这款由 JetBrains 打造的下一代 IDE。 第一部分 – 架构概述第二部分 – 编辑器详解第三部分 – 状态管理第四部分 – 分布式事务第五部分 – 代码补全的故事 在本系列的第三部分和第四部分中,我们探讨了状态管理中涉及的复杂抽象架构概念,以及它们如何在 Fleet 的分布式组件之间进行同步。接下来,我们将研究更熟悉的代码补全功能,看一看它是如何在 Fleet 中实现的。 Fleet 在代码补全领域并不是一项巨大突破,但其架构和分布式特性在各处都留有印记。想象一下:一个典型 Fleet 用户,有幸(或不幸)使用多种编程语言。这类软件开发者会在 Go 和 JavaScript 上苦苦挣扎,更喜欢 Kotlin 和 Rust,还要在文本文件中记笔记。有没有哪种代码补全解决方案能够涵盖所有情况呢?我们来找出答案。 最终用户看到的代码补全 我们先来做一些文本记录。看一看到目前为止的代码补全: 这种行为内置于 Fleet 的编辑器中:它会分析文档,考虑哪些单词是代码补全的良好候选。听起来还算合理,虽然您可能以为是机器学习在根据您先前记下的其他笔记来施展魔法。 接下来,我们转向 Kotlin 编程。 这种补全行为并没有什么特别突出的地方。基本上就是文本记录中的相同

Fleet 后台探秘,第三部分 — 状态管理

在本系列博文中,我们将以多个部分为您介绍构建 Fleet 这款由 JetBrains 打造的下一代 IDE。 第一部分 – 架构概述第二部分 – 编辑器详解第三部分 – 状态管理 在本系列的前几部分中,我们介绍了 Fleet 的总体架构,并探讨了编辑器后台用到的算法和数据结构。 在这一部分中,我们将介绍实现状态管理的方式。 这是一个复杂的主题,因此我们特别准备了多篇博文。 本篇的重点是应用程序状态元素的表示和存储, 下一部分将更细致地探讨 Fleet 中围绕状态管理的事务机制。 Fleet 有很多移动部件,也执行着许多不同的操作,包括: 呈现 UI 元素并与用户互动。与其他服务交互以获取数据和更新 UI 元素。处理文件,例如保存、加载、解析文件以及显示其差异。编排处理代码洞察、补全和搜索结果的后端。 许多操作较为复杂,可能会降低界面的响应能力。 同时,由于 Fleet 是分布式应用程序,可能有多个分布在网络上的前端,使整个过程更加复杂。 尽管如此,我们还是必须持续为用户正确显示所有信息,确保用户可以在前端之间稳定地工作。 在状态管理上,操作分为读取状态和更新状态。 UI 元素读取状态后向用户提供实际数据,用户则通过编辑文档和移动内容来更新状态。 这