标签: hackfest

GTK 黑客节 2020 — 路线图和可访问性

在 1 月 28 日至 1 月 31 日期间，GTK 团队在布鲁塞尔举办了现在的第三届 黑客节。

黑客节的主要议题是

  • GTK4 下一个开发快照的时间表
  • 阻碍 GTK 4.0 发布的缺失功能
  • 工具包中可访问性支持的当前状态

前两项占据了黑客节前两天的大部分时间；您可以阅读GTK 3.98 发布公告，了解自 3.96 版本发布以来，过去 300 天我们一直在做的事情。缺失的功能有

  • 用于键盘快捷键的事件控制器
  • Wayland 上可移动的弹出窗口
  • 行回收列表和网格视图
  • 动画 API

所有这些都在主题分支中进行开发。键盘快捷键分支最近已经重新构建，并且正在进行文档编写和清理；可移动的弹出窗口在经过几次迭代后也正在审查中。最后两个剩余的分支相当庞大，需要更多的迭代才能使它们正确——而动画 API 目前主要是一个原型。

黑客节的最后一个主题是最大的，也是早就应该进行的讨论。

GTK 的可访问性支持由 Sun 可访问性团队作为 GTK 2.0 版本的一部分添加；它依赖于 ATK（辅助工具包）提供的抽象数据类型，然后在 GTK 类（如 GtkWidgetAccessible 或 GtkEntryAccessible）中具体实现。每个小部件都有一个与其关联的“可访问”对象，该对象要么由 GTK 自动创建，要么在子类化 GTK 小部件时由应用程序代码提供。非小部件类型也可以有关联的可访问对象——最值得注意的例子是树视图和组合框的单元格渲染器集。在所有这些的底层，是 AT-SPI，一种由 AT（辅助技术，如屏幕阅读器）用来使用应用程序提供的数据的协议。通常，AT 会使用像 libatspi 这样的库来处理协议本身。

现有堆栈的主要问题是

  • ATK 的存在导致了很多间接性；任何新功能或错误修复都需要在 ATK 内部定义，然后实现到 GTK 和 libatspi 中
  • ATK 是在非常不同的环境中编写的，虽然它已经经历了一些弃用，但它在它所做的假设（如全局坐标空间）和它的设计中显示出了它的年代
  • AT 要求和 GUI 测试的要求之间存在一定的重叠，最终在 API 设计中产生了摩擦
  • 自从 Sun 可访问性团队解散以来，该堆栈已经失修；大部分正在进行的工作仍然主要发生在 AT 空间（如 Orca）和 Web 浏览器中
  • 整个堆栈是在 CORBA 流行时编写的，然后在 GNOME3 时代移植到 DBus；然而，该协议实际上效率不高，需要大量往返来移动少量数据，而不是进行批量操作和通知

最后一点也是为什么我们需要一个单独的可访问性总线以避免垃圾邮件会话总线的原因，并且一旦启用可访问性支持，所有内容都会变慢。一个单独的总线意味着我们需要在任何沙箱中添加一个额外的漏洞，并且仍然允许连接到可访问性总线的任何内容潜在地窥探每个应用程序中发生的事情。

最后，GTK 仅支持 Linux 上的可访问性；没有对 macOS 或 Windows 的支持，这意味着用 GTK 编写并移植到其他平台的应用程序在那里对 AT 不可访问。由于我们在 API 中公开了 ATK，因此在其他平台上添加对可访问性功能的支持将需要桥接 ATK，从而增加复杂性。

由于我们希望重新设计和更新 GTK4 中的可访问性功能，我们需要了解可访问性堆栈的现有使用者有哪些要求，以及我们需要针对哪些用例。为此，我们邀请了 Hypra，一家致力于基于自由和开源软件开发可访问解决方案的公司，来帮助我们。

Hypra 开发人员熟悉 GNOME，并且一直在研究 Linux 可访问性堆栈。他们的客户涵盖了广泛的可访问性用户，因此他们最能描述日常实际使用的 AT 类型。

从工具包到合成器，堆栈的不同层必须提供各种各样的工具和功能；应用程序开发人员还必须访问必要的工具来为 AT 提供适当的支持，因为他们比工具包更了解他们的应用程序应该是什么样子和行为方式。

在两天的时间里，我们确定了一个前进计划

  • 从堆栈中删除 ATK，并让 GTK 直接与 AT-SPI 协议对话；这类似于 Qt 从工具包方面所做的事情，并且可以更容易地扩展和验证最终的协议更改
  • 清理 AT-SPI 协议本身，在需要使用 DBus 更有效率的地方进行更新
  • 删除全局可访问性总线，并让 AT 与每个应用程序协商对等连接
  • 让 AT 要求合成器收集全局状态（如键盘快捷键），而不是与必须询问窗口系统的应用程序对话（如果可能），或者在不可能时返回无效数据
  • 将 GUI 测试与可访问性分离
  • 为应用程序开发人员编写小部件和应用程序创作指南，并提供可作为构建和 CI 过程一部分使用的验证工具，以检查 UI 元素是否具有正确的可访问描述和链接

wiki 上提供了有关笔记和路线图的更多信息，我们已经安排了今年夏天的额外检查点会议。

还有很多工作要做，但我们现在对这种重新设计的范围和交付成果有了更清晰的认识。如果您想帮助加快事情的发生，请随时加入这项工作；您也可以向 GNOME 基金会捐款。

GTK 团队感谢 GNOME 基金会赞助场地和与会者，以及感谢 Hypra 的好人在黑客节加入并解释用例和可访问性堆栈的当前状态，并为开发方面提供帮助。

Guadec 的 GTK BoF

和每年一样，我们在塞萨洛尼基的 Guadec 举办了一个 GTK BoF。今年，我们有了很好的出席率——每个人都对 GTK4 计划感兴趣。

但由于 Emmanuele 上午很忙，我们首先讨论了一些其他主题。

GLib

我们从房间里收集了一些关于有用的 GLib 添加的建议。

  • 用于操作系统信息的 API（基本上是 /etc/os-release 中的数据）。这似乎没有争议；罗伯特将实现它
  • 一个有序的映射。这在很多地方都是通过将哈希表与列表或数组组合在一起临时实现的。似乎大家一致认为在 GLib 中提供这个是有价值的，前提是有人完成提案 API 的工作

对有序映射的讨论也涉及了泛型容器接口；Philipp 描述了如何做到这一点，请参阅 此处 的详细信息。

仍然在容器的主题上，Alex 描述了一个关于传输注释的问题。我们讨论了各种想法，但可能没有完美的解决方案。

Matthias 指出 Pango 中仍然有一些 Unicode 数据。我们简要讨论了如果有一种商定的、可映射的 Unicode 数据二进制格式，以便每个人都可以共享它，那将会多么好。除此之外，将最后一点数据移动到 GLib 是没有争议的。

黑暗模式

由于“黑暗模式”BoF 加入了我们，我们接下来转而讨论黑暗模式。在第二天的 供应商主题 BoF 中对此主题进行了更多讨论；GTK 讨论的重点是如何实现黑暗模式的技术细节。

有多种选择

  • 在主题索引文件中添加额外的元数据以将主题标记为黑暗
  • 添加一个“dark-theme-name”设置，并将黑暗和浅色主题视为独立的
  • 保留现有的在主题名称后附加“-dark”以查找主题的黑暗变体的约定

保留现有约定的务实解决方案似乎得到了与会者的支持。Matthias 开始探索一些应用程序支持 API 这里。

GTK

最终，我们转而讨论 GTK4 的状态和进展。高级总结是，仍然有一个列表的需要为 GTK4 完成的功能

  • 一个可扩展的列表视图，可以回收行小部件。这包括在更多地方更广泛地切换到使用列表模型。为了使其完整，它还应包括使用该技术的网格视图。本杰明正在研究这个
  • 动画的基础设施和API。这类似于 CSS 中动画的工作方式，部分工作不仅是将我们现有的 CSS 动画支持移植过来，还要将堆栈切换动画、揭示器、进度条和微调器移植到新框架。Emmanuele 正在从事这项工作。
  • 完成菜单/弹出框的重构。有些人尝试了新的弹出式菜单栏。反馈是，我们应该回到嵌套子菜单，至少对于菜单栏而言，并推进删除菜单，因为菜单的一些特殊之处（例如保持向上的三角形、滚动）很难保持工作（或保持良好工作）。Matthias 在 Guadec 之后将重新开始这项工作。
  • 快捷方式 - 用事件控制器替换助记符、加速器和按键绑定。有一个相当完整的分支，其中包含一些人已经完成的代码和 API； 欢迎大家帮助审查和测试。
  • 需要完成新的拖放 API。

好消息是，这个列表相当短，并且大多数条目都有负责人。坏消息是，每个条目都是相当大的工作量。因此，在我们合并所有这些条目之前，承诺 4.0 版本的紧凑时间表并不是一个好主意。因此，以下是暂定的，但（我们希望）在某种程度上是现实的

  • 今年年底前再发布一个 GTK 3.9x 快照
  • 在 2020 年春季 GNOME 3.36 发布的同时，发布一个功能完整的 3.99 版本
  • 在 2020 年秋季 GNOME 3.38 发布的同时，发布 4.0 版本

不可避免地，我们也讨论了其他希望拥有的功能。这些都不在 GTK4 的路线图上；但是如果有人出现来完成这项工作，它们就可以实现

  • 一个“小部件存储库”或“hig”库，以便不会用过于特定或实验性的小部件来超载 GTK
  • 一个“UI 设计器”小部件。这个也可以放在一个单独的库中
  • 更好地支持拆分标题栏和状态转换

我们还讨论了 GTK 本身之外的事情，这些事情会阻止应用程序移植到 GTK4。这包括常用的库，例如 GtkSourceView、vte 和 webkitgtk，所有这些都需要 GTK4 端口，然后依赖它们的应用程序才能被移植。其中一些工作已经在进行中；但欢迎大家在这个领域提供任何帮助！

GTK4 移植的另一个潜在障碍是平台支持。GL 渲染器在 Linux 上运行良好；Vulkan 渲染器需要一些修复。在 Windows 上，我们目前使用 cairo 回退，这对于 4.0 可能足够好。或者，我们可以合并使用带有 ANGLE 的 GL 渲染器的现有工作。在 OS X 上的情况不太乐观，我们没有可用的后端；如果您想在这里帮助我们，第一步仍然是使 GDK 后端适应 GDK 的更改。

黑客时间

下午，房间从讨论转向了黑客活动，人们的笔记本电脑上可以看到各种与 GTK 相关的工作正在进行中：加速 GtkBuilder 模板加载的工作、嵌套的弹出菜单、一个半成品 GtkSourceView 端口。

您有望很快在 GTK master 中看到这些（以及其他）内容。

布鲁塞尔 GTK 黑客节的报告

感谢 GNOME 基金会，在 FOSDEM 之后，各种 GTK 开发人员能够在布鲁塞尔聚会，参加我们每年的黑客节之一。

黑客节的主要议题是

  • 回顾过去 6-12 个月内已合并到主分支中的工作，以便让每个人都了解情况
  • 讨论仍在单独分支中进行的功能，评估它们的完成状态，并找出阻碍因素
  • 找出 GTK 4.0 的第一个版本有哪些阻碍因素

与在线沟通渠道相比，黑客节使我们能够以大量的带宽进行这种讨论，因此它们对项目非常重要。

您可以在 wiki 上查看完整议程，我们将确保撰写有关其中最大项目的文章。

讨论的最大项目是引入新的列表模型和列表/网格视图小部件；统一的按键处理 API；将布局管理策略与容器分离，以及引入约束布局管理；合并 libhandy 中的小部件的可能性，以允许编写对外形尺寸变化做出响应的应用程序；切换到纯声明式菜单描述 API，以及删除公共菜单小部件；向 GtkWidget 添加 2D 和 3D 转换；实现应用程序可以使用的动画 API。

  • 列表模型和列表/网格小部件 - 我们真的很想淘汰 GtkTreeView 和 GtkIconView，但现有的替代品 GtkListBox 和 GtkFlowBox 在缩放到非常大和动态的数据集时性能不够好。我们需要更好的数据存储类型，这些类型可以组合以执行映射、过滤和排序等操作，但在调整大小和绘制小部件时也可以避免迭代所有元素。Benjamin Otte 已经向 GTK 添加了各种模型，并且正在开发可以有效显示其内容的列表和网格视图小部件。Benjamin 和其他 GNOME 应用程序开发人员正在确定各种利益相关者，以便专门召开一次黑客节，以收集更多需求并获得对新 API 的反馈。
  • 统一的按键处理 API - 既然我们已经将所有指针和触摸输入处理从事件转移到手势，我们希望对按键处理（如按键绑定、助记符和加速器）也这样做。总体设计基于触发操作，并允许内省 GTK 检查器当前可用的所有“快捷方式”，以便于调试。已经有一个开发分支可用。
  • 布局管理器 - 在 GTK 3 中，布局由容器强加在其子项上；我们希望能够将布局与小部件分离，并将其移动到单独的委托对象层次结构中。布局管理器允许我们降低编写新小部件的复杂性；它们将布局代码保留在单独的、不可派生的类型中；并且它们允许我们简化工具包内部结构，以至于我们甚至可能会在未来使 GtkWidget 成为可实例化的类型。布局管理器是将基于约束的布局管理添加到 GTK 的第一步，这将摆脱嵌套框来创建复杂的 UI。已经有一个开发分支可用。有关约束布局的更多信息，您可以查看用于 GTK 3 的 Emeus 实验库。
  • 合并 libhandy 中的小部件 - Adrien Plazas 概述了 libhandy 当前提供的功能，以及将来直接从 GTK4 获取哪些功能会很有用。我们讨论了反应式布局，以及使用百分比表达大小的能力，以及可能使用约束来获得类似的结果。
  • 声明式菜单 - 多年来，GTK 已经迭代了不同的菜单 API；从使用小部件构建菜单，到 GtkUIManager，到 GtkBuilder，到 GMenu；为了让窗口系统更准确地显示弹出菜单，而无需暴露全局坐标，我们还转向了声明弹出菜单的行为。有很多重叠，但没有明确的赢家，主要是因为我们仍然允许使用小部件来构建应用程序菜单和上下文菜单。完全切换到声明式风格的菜单，添加新的 API 以使其更具表现力，并将 GtkMenu 及其友元设为工具包的私有实现，将使我们能够获得诸如能够检查所有菜单（即使是进程外的）之类的功能；由插件系统操作的菜单，而无需创建小部件并跟踪它们；避免定位错误。wiki 上提供了完整的初步提案，Matthias Clasen 正在一个开发分支中将上下文菜单切换到 GMenu。
  • 小部件转换 - 可悲的是，Timm Bädert 无法参加黑客节，但我们一直在审查他的开发分支，该分支向 GTK 小部件添加了 2D 和 3D 转换，我们对此感到非常兴奋。
  • 动画 - 我们希望为 GTK4 引入的最后一件事是用于 GTK 小部件的动画框架，以替换当前的通用“帧刻度回调”。其模型是 Clutter 显式动画 API，后者又是基于 Core Animation 和 CSS3 过渡。这项工作仍处于设计阶段，但您可以期望很快会有相关的开发分支。

除了大议题之外，我们还讨论了各种较小的议题

  • 提高性能和内存使用率；我们希望在帧时钟阶段公开 SysProf 计数器，以便我们可以轻松识别问题。
  • 改进测试套件，尤其是在报告故障方面；现在，我们必须查看 CI 失败日志，但我们希望使用 GitLab CI 基础设施发布正确的报告
  • 用辅助对象上的真实 GObject 属性替换子属性，尤其是对于布局管理器；这将使文档、内省和用法更加清晰。
  • 完成拖放功能的重构，以获得更现代的 API。
  • 添加一个顶层接口用于“类似窗口”的对象，例如窗口、对话框、弹出框、菜单/弹出窗口，这有助于建立通用行为，并消除 GtkWindow 中的黑客行为和复杂性。

最后，是的：我们确实从 GTK 中移除了“加号”。 ;-)

来自 Guadec GTK+ BoF 的报告

GTK+ 团队在 Guadec 的 BoF 日期间进行了一整天的计划会议，我们挤满了整个房间，其中不仅包括 GNOME 的代表，还有来自几个下游项目的代表。

我们也有一个相当紧凑的议程。

GTK+ 3

我们首先回顾了我们之前概述的 GTK+ 3 计划。

除了那里提到的内容之外，我们还计划反向移植新的事件控制器，以便更容易移植到 GTK+ 4。我们还将添加 meson 构建支持以帮助进行 Windows 构建。

3.24 版本实际上将是 3.22 分支的延续，并且应该可以完全安全地作为稳定更新发布到发行版中。

我们计划在 GNOME 3.30 发布时及时发布 GTK+ 3.24.0。

GTK+ 4 遗留问题

当天的大部分时间都用于讨论 GTK+ 4。我们回顾了路线图上剩余的任务列表

  • 完成 DND：GTK+ 级别的姿势，本地快捷方式
  • 引入 GtkToplevel 并干净地支持弹出框
  • 添加变换
  • 创建一个快捷方式事件控制器来替换键绑定
  • 将 GtkTextView 移植到渲染节点
  • 分析 cairo 后端，确保其性能与 GTK+ 3 持平
  • 移植各种依赖库
    • vte
    • webkit
    • libchamplain
    • gtk-vnc
    • gtk-spice

这些任务中的大多数都有人负责，但如果您想帮助完成其中任何一项任务，请务必联系我们！

此列表中明显缺少一些之前在路线图上的内容

  • 基于约束的布局 (emeus)
  • 着色器编译器和应用程序提供的着色器
  • 设计器支持

如果出现合并请求，所有这些仍然可以实现，但我们认为不应该因为它们而阻塞。它们可以在 GTK+ 4 外部进行开发，并成为 GTK+ 5 的内容。

GTK+ 后端

我们花了一些时间评估 GTK+ master 中 GDK 后端的状态。

Windows 后端状态良好。我们有几个人在帮助维护和开发其功能，meson 使构建它变得容易得多，并且我们为此配备了 ci。

Quartz 后端的状态要糟糕得多。它没有保持在可构建的状态，没有人为其提供修复或功能开发，并且我们没有 ci。我们提供了一台可用于 ci 的 macbook，并且有人建议我们可以使用 travis ci 进行 OS X 测试。

GTK+ 时间线

我们在这方面花费了很长时间，但并没有达成 100% 的共识，但是如果我们在剩余的遗留问题上保持良好的进展，那么在 2019 年春季发布 GTK+ 4 似乎是现实的。

当我们发布 GTK+ 3.96 时，我们还将宣布 GTK+ 4.0 的发布日期。我们希望能够在 GNOME 3.32 之前发布，以便 GNOME 应用程序开发人员可以将他们的 master 分支切换到 GTK+ 4，而无需担心这会扰乱 3.32 的其他开发。

应用程序移植

我们现在真的希望收到应用程序移植的反馈。但是我们处于一个有点困难的境地，因为在 GtkToplevel 和快捷方式控制器工作完成之前，我们不能信誓旦旦地声称主要 API 工作已经完成。

我们目前对应用程序作者的建议是

  • 如果你有点冒险精神，可以在一个分支上移植到 3.94 版本。在 GTK+ 4 开发的剩余时间里，应该可以在不进行太多工作的情况下使其保持正常运行。
  • 如果你不是那么有冒险精神，请等到 3.24 发布，使用它来准备你的移植，然后移植到 GTK+ 3.96。
  • 无论如何，请将你的移植版本提供给用户进行测试，无论是作为常规版本还是作为带有捆绑 GTK+ 的 Flatpak。

GLib 分流

下午，我们花了一些时间讨论 GLib。我们回顾了一系列大小项目。值得注意的亮点：GProperty 可能会在 2.60 中实现，我们可能很快就能使用 g_autoptr。

其他想法

我们讨论了大量其他我们可以而且应该做的事情。

例如，有人建议（并且普遍同意）我们应该将 gsk 合并到 gdk 中，因为它很小而且内部结构有些交织。还建议在 gtk/ 中创建子目录，例如用于 css 机制。