作者: Emmanuele Bassi

GTK 4.14 中的辅助功能改进

GTK 4.14 在辅助功能方面带来了各种改进，特别是对于显示复杂格式化文本的应用程序、WebKitGTK 以及通知。

可访问文本接口

4.0 的辅助功能重写为 GTK 提供的部件（如 GtkTextView）中复杂的、可选择的和格式化的文本提供了一个实现，但树外部件无法做到这一点，因为 API 在我们讨论 AT（辅助技术）实际需要什么以及我们研究非 Linux 实现时保持私有。对于 GTK 4.14，我们终于有了一个公共接口，树外部件可以实现该接口，以向 AT 提供复杂、格式化的文本：GtkAccessibleText。

GtkAccessibleText 允许部件提供给定偏移处的文本内容；应用于内容的文本属性；以及通知辅助技术文本、插入符位置或选择边界的变化。

实现 GtkAccessibleText 的文本部件应在以下情况下通知 AT

文本属性主要留给应用程序来实现——无论是在命名还是序列化中；GTK 为各种工具包和辅助技术已使用的常见文本属性提供支持，它们在 API 参考中以 GTK_ACCESSIBLE_ATTRIBUTE_* 前缀下的常量提供。

GtkAccessibleText 接口是实现虚拟终端辅助功能的必要条件；最常见的基于 GTK 的虚拟终端库 VTE 由于 Christian Hergert 的努力已被移植到 GTK4，并且在 GNOME 46 中将通过新的 GTK 接口支持辅助功能。

桥接 AT-SPI 树

在某些情况下，库或应用程序会使用 AT-SPI 实现自己的可访问树，无论是在同一进程中还是在进程外。其中一个库是 WebKitGTK，它从单独进程内的 Web 树生成可访问对象树。这些进程不使用 GTK，因此它们无法使用 GtkAccessible API 来描述其内容。

由于 Georges Stavracas 的工作，GTK 现在可以将这些辅助功能对象树桥接到 GTK 部件自己的树下，允许 AT 从 UI 使用 WebKit 导航到网页中。

目前，与 GTK 中的其余辅助功能 API 一样，这特定于 Linux 上的 AT-SPI 协议，这意味着希望利用它的库和应用程序必须确保 API 在编译时可用，通过使用 pkg-config 文件和单独的 C 头文件，类似于公开打印 API 的方式。

通知

使用与当前部件焦点分离的应用内通知的应用程序，例如 libadwaita 中的 AdwToast，现在可以通过 gtk_accessible_announce() 方法将通知消息提升到 AT，这要感谢 Lukáš Tyrychtr，其方式尊重当前的 AT 输出。

其他改进

GTK 4.12 确保计算出的可访问标签和描述与 ARIA 规范保持同步；GTK 4.14 通过删除特殊情况和重复项来迭代这些改进。

感谢来自 文档基金会的 Michael Weghorn 的工作，文本相关的可访问对象有了新的角色，例如段落和注释，以及辅助功能 API 的 AT-SPI 实现中的各种修复。

由于许多人的贡献，GTK4 中的辅助功能支持正在随着每个周期逐步改进；理想情况下，这些改进也应导致工具包和辅助技术共享的更好、更高效的协议。

我们仍在探索为其他辅助功能平台（如 UIAutomation）和其他库（如 AccessKit）添加后端的可能性。

GTK 文档

您可能已经注意到，最近在 GNOME 开发人员文档网站上发生了一些各种更改。这些更改也影响了 GTK 及其核心依赖项的 API 参考。

发生了什么变化

主要变化是 GTK 为其 API 参考和辅助文档迁移到了一个新的文档工具，称为 gi-docgen。与之前的文档工具 gtk-doc 不同，gi-docgen 使用基于 GObject 的库生成的自检数据来构建 API 参考。这有多个好处

  • gi-docgen 更易于运行并集成到现有库中，因为它只有一个项目描述文件，并且依赖于自检数据进行其他所有操作；此外，它可以很容易地作为 Meson 子项目包含在内
  • gi-docgen 到处都使用 Markdown，而不是 DocBook
  • gi-docgen 速度快得多，因为它不会执行额外的源代码解析步骤；它没有通过 xsltproc 进行 XML 到 HTML 转换的瓶颈；并且它不必解析 Devhelp 文件来修复在生成参考后对其他库的交叉引用
  • gi-docgen 可以推断出有关 API 的更多信息，因为它可以访问库的整个自检数据，包括其依赖项；这允许自动生成更准确和一致的文档，而不是依赖于人工来完成这项工作
  • gi-docgen 为所有 API 入口点和附加文档生成稳定的 URL，这意味着可以更轻松地链接到它和从它链接，而无需使用晦涩的引用
  • 默认文档模板可在不同的外形和布局上使用；它尊重支持它的 Web 浏览器上的深色主题选项；并提供不依赖于第三方服务的树内实时搜索功能
  • gi-docgen 也可以在树外运行——这在以后会派上用场

除了这些改进之外，使用自检数据作为文档的来源还有其他好处：它使我们在向非 C 用户公开的 API 类型上保持诚实；并且它使 C API 参考更接近使用相同数据的其他语言的参考。

GTK4、Pango 和 GdkPixbuf 已迁移到这个新工具，在我们进行迁移时，我们还审查了文档，以提高其一致性和准确性——特别是对于 API 的较旧部分。

新的 API 参考可以通过 Devhelp 41 离线使用，它将于明年 9 月与 GNOME 41 一起发布。

在线文档

GTK 参考的规范在线位置现在是 docs.gtk.org。您可以在那里找到以下 API 参考

GTK3 和 ATK 的 API 参考也已移至 docs.gtk.org。

docs.gtk.org 网站由 GTK CI 管道生成，因此它始终与存储库的状态保持最新；由于 gi-docgen 支持树外构建，该网站还可以为尚未移植到 gi-docgen 的各种库（如 GLib、GTK3 和 ATK）生成文档。

已知问题

当然，任何大的变化都会带来副作用。

主要问题是文档 URL 的更改；引用 developer.gnome.org 上位置的现有文档必须修复。感谢 GNOME 系统管理员，我们有一些重定向到位，并且有一些关于如何改进它们的想法，而不会创建一个无法维护的静态重定向混乱。

新的文档网站正在被各种搜索引擎索引；您使用它的次数越多，链接到它的次数越多，新的参考就越容易在排名中上升。在任何情况下，我们都强烈建议您使用搜索功能：只需按“s”键即可开始搜索符号和类型，甚至搜索额外文档页面中的内容。

不幸的是，考虑到 C API 的低级别，GLib 的自检数据存在一些问题；我们正在努力改进它，这将不仅对文档产生影响，还会对 API 在其他语言中的整体绑定性产生影响。

GLib、GObject、GIO 和 GTK3 的文档仍然是为 gtk-doc 编写的；这意味着文档中的交叉链接可能不起作用；内容可能无法很好地呈现；或者可能存在多余的段落。这将在未来通过 gi-docgen 中的更改（在可能的情况下）和通过更新库内部的文档来修复。这也将改进语言绑定文档，因为它们使用与 gi-docgen 相同的自检数据。非常欢迎在这方面提供帮助。

GTK 4.2.0

GTK 4.2.0 现在可以在通常的下载地点下载。

此版本是应用程序开发人员将其项目移植到 GTK4 的初始反馈结果，因此主要包含错误修复和 API 改进。但我们也添加了新功能，例如新的 GL 渲染器；工具包处理组合键和死键序列方式的各种改进；用于在 Windows 和 macOS 上编译 GTK 的构建系统改进；以及一个全新的 API 参考，该参考由语言绑定也使用的相同自省数据生成。

有关更多信息，您可以查看之前关于 4.1 开发周期的博客文章。

NGL 渲染器

感谢 Christian Hergert 的辛勤工作，NGL 渲染器现在是 Linux、Windows 和 macOS 的默认渲染器。我们从使用 Lima 等驱动程序的移动平台用户那里获得了非常积极的反馈，帧速率、功耗和 CPU 使用率都有显著提高；后两者也将对台式机和笔记本电脑用户产生积极影响。NGL 渲染器才刚刚起步：新的代码库将允许我们在未来进行更多改进。

目前，我们保留了旧的 GL 渲染器；您可以在环境中使用 export GSK_RENDERER=gl 来返回到 4.0 GL 渲染器，但如果您需要这样做，请务必提交问题，以便我们有机会修复 NGL 渲染器。

输入

Matthias 写了一篇关于处理组合键和死键输入序列的完整博客文章，所以您只需阅读它。为了处理输入堆栈下层中引入的怪异之处和解决方法，死键处理经历了几次迭代。

在某些键盘布局中，处理死重音符与撇号之间存在一个已知问题，目前仍在调查中。如果您发现键盘输入方面存在其他问题，特别是围绕组合序列或死键的问题，请提交问题。

可移植性

GTK 的目标之一是拥有一个“交钥匙”构建系统，能够从 Git 存储库的克隆到工具包的完全可部署安装，而无需手动处理所有依赖项或使用奇怪的装置。您可以在我们 Collabora 的朋友的这篇文章中了解它在 Windows 上使用本机工具的工作原理。

此外，我们现在确保您可以将 GTK 用作 Meson 子项目；这意味着您可以将 GTK 及其所有依赖项构建为应用程序构建环境的一部分，并且可以使用您选择的工具链轻松收集所有构建工件，以便与您的应用程序一起分发。

文档

对于 GTK 的新手来说，最著名的问题之一是文档。不熟悉我们 API 的应用程序开发人员经常发现很难在我们的文档中找到信息；此外，API 参考的样式和结构已经很久没有更新了。为了改善第一印象和文档的使用，GTK 已切换到新的文档生成器，称为gi-docgen。这个新工具为 API 参考添加了新功能，例如在文档中客户端搜索术语；以及一些不错的小可用性改进，例如

  • 代码片段和示例的“复制到剪贴板”按钮
  • 每个类的祖先和接口的可视层次结构
  • 类中继承的属性、信号和方法列表
  • 响应式设计，使其更容易在小屏幕上使用 API 参考

API 的好坏取决于它允许开发人员以最惯用的方式使用它。GTK 不仅具有 C API，还通过GObject 自省公开了供语言绑定使用的整个 API。新文档使用相同的数据，这不仅使我们能够将构建时间缩短一半，而且还从源代码中的注释生成公共文档位，使 API 参考更加一致和可靠；最后，C API 参考与语言绑定作者在使用自省数据时看到的内容相匹配，这意味着在引入新 API 时，我们将加强工具包和绑定开发人员之间的反馈循环。

Pango 和 GdkPixbuf 也已切换到 gi-docgen，这使我们能够通过我们的 CI 管道为各种依赖项构建 API 参考，并将其发布到全新的网站：docs.gtk.org。您始终可以在那里找到最新版本的 GTK 文档。

其他杂项

当然，除了这些可见的更改之外，我们还有一些较小的更改

  • 从用于渲染内容的 GLSL 着色器到按需创建而不是预先创建的辅助功能对象，所有方面的性能都有所提高
  • 当使用具有适当 API 的较新版本的 Cairo 时，文本的亚像素定位
  • 表情符号选择器的响应式布局
  • 改进了弹出窗口小部件中阴影的渲染
  • 微调按钮中的本地化数字
  • 改进了对 Wayland 输入法协议的支持
  • 提高了文本视图小部件的滚动性能

数字

GTK 4.2 是四个月开发的结果，来自 54 位开发人员的 1268 个单独的更改；总共添加了 73950 行代码，删除了 60717 行代码。

变更集最多的开发人员
Matthias Clasen 843 66.5%
Emmanuele Bassi 124 9.8%
Timm Bäder 87 6.9%
Christian Hergert 33 2.6%
Jakub Steiner 24 1.9%
Benjamin Otte 21 1.7%
Chun-wei Fan 15 1.2%
Alexander Mikhaylenko 14 1.1%
Fabio Lagalla 10 0.8%
Bilal Elmoussaoui 8 0.6%
Carlos Garnacho 6 0.5%
Ignacio Casal Quinteiro 6 0.5%
Michael Catanzaro 6 0.5%
Emmanuel Gil Peyrot 5 0.4%
Xavier Claessens 4 0.3%
David Lechner 4 0.3%
Jan Alexander Steffens (heftig) 4 0.3%
Kalev Lember 3 0.2%
wisp3rwind 3 0.2%
Mohammed Sadiq 2 0.2%
更改行数最多的开发人员
Matthias Clasen 38475 42.6%
Emmanuele Bassi 15997 17.7%
Christian Hergert 13913 15.4%
Kalev Lember 9202 10.2%
Timm Bäder 5890 6.5%
Jakub Steiner 2397 2.7%
Benjamin Otte 902 1.0%
Chun-wei Fan 783 0.9%
Ignacio Casal Quinteiro 717 0.8%
Fabio Lagalla 292 0.3%
Marek Kasik 267 0.3%
Alexander Mikhaylenko 254 0.3%
Emmanuel Gil Peyrot 232 0.3%
Simon McVittie 214 0.2%
Jan Tojnar 83 0.1%
wisp3rwind 74 0.1%
Jan Alexander Steffens (heftig) 65 0.1%
Carlos Garnacho 62 0.1%
Michael Catanzaro 61 0.1%
Ungedummt 60 0.1%
删除行数最多的开发人员
Emmanuele Bassi 8408 13.8%
Jakub Steiner 1890 3.1%
Timm Bäder 493 0.8%
Simon McVittie 203 0.3%
Emmanuel Gil Peyrot 146 0.2%
Chun-wei Fan 43 0.1%
Jan Tojnar 26 0.0%
Alexander Mikhaylenko 25 0.0%
Jonas Ådahl 17 0.0%
Luca Bacci 13 0.0%
Robert Mader 4 0.0%
Chris Mayo 3 0.0%
Bartłomiej Piotrowski 2 0.0%
Marc-André Lureau 2 0.0%
Jan Alexander Steffens (heftig) 1 0.0%
Tom Schoonjans 1 0.0%

谁编写了 GTK4

GTK 4 是一项耗时多年的巨大开发工作，于 2016 年 10 月开始，于 2020 年 12 月结束。现在 4.0 版本终于发布了，是时候回顾一下这四年中数百名贡献者所做的令人难以置信的工作了。

早在 2016 年，我们对时间表肯定有点乐观，认为我们可以在三年内（到 2019 年底）发布 4.0 版本。该计划首先更改 GTK 的渲染管道，将其移动到可以提交到 GPU 的操作的保留图，而不是自工具包一开始就拥有的立即模式渲染，并且这种渲染方式经历了两个主要的 API 周期——首先是抽象 Xlib 绘图命令，然后是迁移到 Cairo 操作。当然，我们也知道我们希望改进其他子系统，例如输入和窗口系统 API，以摆脱 X11 主义，并朝着更符合 Wayland（和其他窗口系统）要求的方向发展。经过一切努力，我们得到的是对工具包内部结构的深度重新设计，以及一种不同的编程模型，该模型倾向于通过辅助对象进行更多委托，并减少泄漏的抽象和深类型层次结构；此外，我们精简了暴露的内部结构，以确保工具包及其使用的应用程序在未来更易于维护。缺点是 GTK 不再是“元工具包”，其内部状态可以从外部进行探测，同时期望跨多个版本工作；从长远来看，考虑到可用的资源，这种方法是不可持续的，并且使我们无法优化或改进 GTK 的内部结构，从而损害了每个用户。

我们不希望下一个主要开发周期花费这么长时间，但正如他们所说：任何行动计划都不能确定地延伸到与主要敌对势力首次接触之后。然而，重要的是，我们仍然看到了改进的潜力；虽然我们想庆祝 GTK4 的发布，以及为之做出贡献的每个人，但我们也想传达2016 年概述的计划仍然非常有效。我们已经在我们的 GitLab 项目页面中开始收集 GTK5 开发周期的项目，并且我们计划与各个利益相关者就未来的工作方向进行更多讨论。

一些统计数据

从 2016 年 10 月 5 日的提交 4cce6104 开始

  • 总提交次数: 16852
  • 开发人员: 256
  • 雇主: 10
  • 添加的行数：1053492，删除的行数：1053542（差额：-50）

最有趣的是，经过所有这些工作，我们最终从现有代码库中删除了总共 50 行代码，其中包括测试和文档。

按年细分

年份 开发人员 提交次数 添加的行数 删除的行数 差额
2016 50 1422 64014 152103 -88089
2017 84 3446 186024 166198 19826
2018 111 2332 129726 140526 -10800
2019 85 3244 200476 207623 -7147
2020 109 6384 470907 386761 84206

我们在 2016 年只有几个月的时间，10 月到 12 月之间最大的努力是删除已弃用的 API，以及为应对从 GTK3 到 GTK4 的重命名而进行的各种更改。尽管如此，GSK 最初还是在 11 月/12 月登陆的。11 月 21 日，发布了 GTK 3.89.1，这是新 GTK 4 API 的第一个开发快照。

在 2017 年，GSK 的 API 经历了多次迭代：添加了新的渲染节点来实现 CSS 绘图原语，并将小部件从旧的 Cairo 渲染原语移动到了 GtkSnapshot API。此外，还引入了新的剪贴板 API，其中采用了基于流的实现。3 月 31 日，发布了 GTK 3.90.0，随后在 10 月发布了 3.92.0。

2018 年，情况似乎有所放缓，但这主要是因为我们迁移到了 GitLab。突然之间，我们能够使用 CI 管道和合并请求，并且我们对我们的开发流程越来越有信心；大量工作发生在开发分支中，特别是大型重构，例如将 GdkWindow 重命名为 GdkSurface；迁移到 GtkGesture 对象并删除每个小部件的事件信号；或者使叶子类不可派生。GTK 3.94.0 于 6 月发布。

2019 年，开发速度再次加快

  • 小部件转换
  • 布局管理器
  • 约束布局
  • 不再有 GtkMenu
  • 用于 GtkBuilder 的作用域对象
  • GtkText 小部件
  • GtkNative 和 GtkRoot 接口
  • 每个小部件的动作
  • 简化的 GdkSurface 子类型

此外，当然，渲染管道中还有大量的性能和功能改进。GTK 3.96.0 于 5 月发布。

最后，我们来到了 2020 年

  • 基于事件控制器的全新拖放 API
  • GDK 中新的 macOS 后端，取代了旧的 Quartz 后端
  • 新的无障碍功能 API，放弃了 ATK
  • 不再有 GtkContainer
  • 不再有 GtkRadioButton
  • 简化的 GdkDevice API
  • 新的键盘快捷键 API
  • 新的表达式和过滤器模型
  • 新的基于模型的列表和树小部件

GTK 3.98.0 于 2 月发布；最后，3.99.0 于 7 月发布，作为迈向 GTK 4.0 的第一个真正测试版。

 

开发人员

提交次数前 20 名
Matthias Clasen 6519 (38.7%)
Timm Bäder 3229 (19.2%)
Benjamin Otte 2596 (15.4%)
Emmanuele Bassi 1094 (6.0%)
Carlos Garnacho 494 (2.9%)
Daniel Boles 383 (2.3%)
Alexander Larsson 313 (1.9%)
Jonas Ådahl 167 (1.0%)
Chun-wei Fan 162 (1.0%)
Christian Hergert 158 (0.9%)
Jakub Steiner 134 (0.8%)
Piotr Drąg 132 (0.8%)
Руслан Ижбулатов 120 (0.7%)
Alexander Mikhaylenko 93 (0.6%)
Rico Tzschichholz 78 (0.5%)
nana-4 66 (0.4%)
Christoph Reiter 62 (0.4%)
Tim-Philipp Müller 60 (0.4%)
Mohammed Sadiq 57 (0.3%)
Olivier Fourdan 42 (0.2%)
更改次数前 20 名
Matthias Clasen 620248 (36.8%)
Benjamin Otte 466996 (27.7%)
Timm Bäder 187516 (11.1%)
Emmanuele Bassi 165354 (9.8%)
Alexander Larsson 53065 (3.1%)
Carlos Garnacho 27227 (1.6%)
Christian Hergert 26964 (1.6%)
Руслан Ижбулатов 21760 (1.3%)
Jakub Steiner 18388 (1.1%)
Jonas Ådahl 12824 (0.8%)
Chun-wei Fan 12518 (0.7%)
Daniel Boles 12371 (0.7%)
Lapo Calamandrei 9995 (0.6%)
Christoph Reiter 8391 (0.5%)
Alexander Mikhaylenko 4936 (0.3%)
Tim-Philipp Müller 3932 (0.2%)
Rico Tzschichholz 3108 (0.2%)
William Hua 2900 (0.2%)
Jason Francis 1908 (0.1%)
Peter Bloomfield 1727 (0.1%)

像往常一样，Matthias 在提交的绝对数量和代码更改方面都远远超过其他所有贡献者。

雇主

按提交次数
红帽 13706 (81.3%)
（未知） 1185 (7.0%)
GNOME 基金会 1095 (6.5%)
GNOME 571 (3.4%)
Purism 93 (0.6%)
Canonical 84 (0.5%)
Centricular 75 (0.4%)
Endless 20 (0.1%)
Collabora 14 (0.1%)
英特尔 6 (0.0%)
Novell 3 (0.0%)
按更改次数
红帽 1415771 (84.0%)
GNOME 基金会 165355 (9.8%)
（未知） 58220 (3.5%)
GNOME 33442 (2.0%)
Purism 4936 (0.3%)
Centricular 4205 (0.2%)
Canonical 3347 (0.2%)
Novell 336 (0.0%)
英特尔 222 (0.0%)
Collabora 208 (0.0%)
Endless 121 (0.0%)
按贡献者
（未知） 199 (72.4%)
GNOME 32 (11.6%)
红帽 22 (8.0%)
Endless 6 (2.2%)
Collabora 4 (1.5%)
Centricular 3 (1.1%)
Novell 3 (1.1%)
GNOME 基金会 2 (0.7%)
Canonical 2 (0.7%)
英特尔 1 (0.4%)
Purism 1 (0.4%)

虽然红帽员工的贡献最多，但我们仍然有来自社区的大量贡献者——既使用他们的 GNOME 电子邮件地址，也使用他们的工作地址，即使是在个人层面上做贡献。我们还有来自 GNOME 和整个自由软件生态系统中多家公司的多位贡献者，这表明该项目周围的社区是健康的。

与 GTK3 比较数字有点棘手

  • GTK 2 → 3 的开发阶段只用了大约一年多一点的时间，而不是四年
  • 我们仍然在使用旧的 GNOME 基础设施，这意味着更少、更大的补丁，以及以 Bugzilla 的形式提高了贡献的门槛

尽管如此，与 2011 年相比，贡献者的数量增加了一倍以上，其中非附属贡献者的数量几乎增加了三倍。

¹ – GNOME 基金会的付费员工。

² – 使用 gnome.org 电子邮件地址且没有明确就业状况的贡献者。

构建和测试 GTK

... 或者：GTK 开发人员如何检查他们在工具包上的工作.

自从 GNOME 集体迁移到 GitLab 以来，GTK 一直在利用该平台提供的功能——尤其是在其持续集成管道方面。

在过去，检查我们对工具包的更改是否正确的唯一方法是等到 持续构建机器人通知我们主开发分支上的任何中断。虽然这比没有好，但它不允许我们在任何开发阶段（从功能到错误修复，从文档改进到添加新测试）期间防止中断。

现在，GitLab 中可用的 CI 管道在每个分支和合并请求上运行，远早于更改到达其他所有人使用的公共开发分支。

主题分支和合并请求

当针对 GTK 4 主开发分支开发主题分支时，我们会运行一个 CI 管道，该管道首先对分支中应用的更改进行简单的编码风格检查。样式检查使用 clang-format，这通常足以满足 GTK 编码风格；编码风格有一些“特殊”注意事项，并且 clang-format 可能会产生误报和漏报。因此，允许样式检查失败，但强烈建议贡献者和审阅者在失败时检查日志。

一旦通过样式检查，我们将运行构建阶段，该阶段目前包含三个单独的作业

  • 使用 Fedora 容器的 Linux 调试版本
  • Windows 上的 MSYS2 构建
  • Linux 发布版本

Linux 调试版本非常标准。

MSYS2 版本可以捕获 Windows 上 GNU 工具链的任何问题。

发布版本对于确保我们不依赖于开发过程中调试代码的副作用是必要的。

所有这些作业都运行 GTK 测试套件。

我们将测试报告同时发布为 JUnit 文件，利用 GitLab 的支持；并发布为 HTML 报告，存储为管道工件。这使我们更容易检查哪些失败以及哪些成功。

理想情况下，我们希望添加更多环境

  • 基于其他主流发行版的 Linux 构建
  • 使用 MSVC 工具链的 Windows 构建
  • 一旦 GDK 后端修复后，进行 macOS 构建

在构建和测试作业通过后，我们进入分析阶段。我们在 GTK 的代码库上运行 Clang 静态分析工具并生成报告。在不久的将来，我们还可以运行像 UBSan 和 ASan 这样的消毒工具；用于我们的解析器（如 GtkBuilder 和 CSS）的模糊测试工具；或验证我们的 UI 定义是否包含适当的无障碍描述符的工具。

就像测试一样，我们将分析报告作为 GitLab 工件发布以供审查。

一旦分析阶段通过，我们将构建 API 参考，并检查结果，以便正确记录新添加的符号。

最后，我们有手动 CI 作业来构建 GTK 演示应用程序、小部件工厂和图标浏览器的 Flatpak 包。这使设计人员可以立即测试 Adwaita 中的更改或新添加的小部件，而无需在他们的系统上从头开始构建 GTK。

主线开发分支

一旦主题分支/合并请求的 CI 管道通过，我们就可以将更改合并到主开发分支中，并且有一定的信心代码是正确的并且可以执行我们想要的操作。

主开发分支运行与先前描述的相同的管道，不同之处在于 Flatpak 作业不再是手动的了——因此始终可以在本地测试 GTK 的最新版本。此外，文档在 在线发布，因此它始终是最新的。

The GTK CI pipeline

GTK 3 怎么样？

在 GTK 3 分支中，我们有一个更简单的管道，它运行以下作业

  • 在 Linux 和 Windows/MSYS2 上使用完整的 Meson 调试版本，用于 Fedora 和 Debian 当前稳定版本的静态和共享库工件
  • 在 Linux 上使用完整的 Meson 发布版本，该版本还会生成 API 参考
  • 在 Linux 和 Windows/MSYS2 上使用 Autotools 构建
  • 在 Linux 上使用可选的 Autotools distcheck 构建

只要 GTK 3 支持 Autotools，Autotools 作业就会到位。理想情况下，我们希望利用 Meson 构建为 macOS 和 Windows/MSVC 添加其他作业。

The GTK3 CI pipeline

一旦 GTK 4 CI 管道达到一定的功能和稳定性水平，我们将将其向后移植到 GTK 3，这样我们就可以更加确信当前的稳定分支不会倒退。

有关更多信息，您可以查看 GTK 存储库

GTK Hackfest 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 的各位同事参加黑客马拉松，解释用例和当前辅助功能堆栈的状态，以及在开发方面提供帮助。

约束布局

什么是约束

最基本地，约束是两个值之间的关系。该关系
可以描述为线性方程

target.attribute = source.attribute × multiplier + constant

例如，这个

可以描述为

blue.start = red.end × 1.0 + 8.0

或

  • 约束将要设置的目标 “blue” 的属性 “start”；这是等式的左侧
  • 等式左侧和右侧之间的关系，在本例中为相等；关系也可以是大于或等于
    和小于或等于
  • 约束将要读取的源 “red” 的属性 “end”；这是等式的右侧
  • 应用于源的属性的乘数 “1.0”
  • 添加到属性的偏移量常量 “8.0”

约束布局是一系列如上所述的方程，描述 UI 各个部分之间的所有关系。

重要的是要注意，关系不是赋值，而是相等（或不相等）：等式的两侧将以满足约束的方式求解；这意味着可以重新排列约束列表；例如，上面的例子可以改写为

red.end = blue.start × 1.0 - 8.0

通常，为了方便和可读性，您应该按照阅读顺序排列约束，从前导边缘到尾随边缘，从上到下。您还应该优先为乘数使用整数，为常量使用正数。

求解布局

线性方程组可以有一个解、多个解，甚至根本没有解。此外，出于性能原因，您并不真的希望每次都重新计算所有解。

早在 1998 年，Greg J. Badros 和 Alan Borning 发表了用于求解线性算术约束的 Cassowary 算法，以及其在 C++、Smalltalk 和 Java 中的实现。Cassowary 算法尝试通过找到其最佳解来求解线性方程组；此外，它是增量进行的，这使得它对于用户界面非常有用。

在过去的十年中，各种平台和工具包开始提供基于约束的布局管理器，并且大多数都使用了 Cassowary 算法。第一个是 2011 年的 Apple 的 AutoLayout；2016 年，Google 将 ConstraintLayout 添加到 Android SDK 中。

2016 年，Endless 在一个名为 Emeus 的库中为 GTK 3 实现了约束布局。从这项工作开始，GTK 4 现在为应用程序和小部件开发人员提供了一个可用的 GtkConstraintLayout 布局管理器。

实现约束求解器的机制是 GTK 私有的，但公共 API 提供了一个布局管理器，您可以将其分配给 GtkWidget 类，以及一个不可变的 GtkConstraint 对象，该对象描述您希望添加到布局的每个约束，将两个小部件绑定在一起。

引导约束

约束使用小部件作为源和目标，但是在某些情况下，您希望将小部件属性绑定到实际上不在屏幕上绘制任何内容的矩形区域。您可以在布局中添加一个虚拟小部件，然后将其不透明度设置为 0 以避免渲染它，但这会给场景增加不必要的开销。相反，GTK 提供了 GtkConstraintGuide，该对象唯一的任务是为布局做出贡献

An example of the guide UI element

在上面的示例中，只有标记为 “Child 1” 和 “Child 2” 的小部件将可见，而引导线将是一个空白区域。

引导线具有最小、自然（或首选）和最大尺寸。所有这些都是约束，这意味着您不仅可以将引导线用作对齐的辅助工具，还可以将其用作布局中可以增长和收缩的灵活空间。

描述布局中的约束

约束可以以编程方式添加，但像 GTK 中的许多内容一样，为了方便起见，它们也可以在 GtkBuilder UI 文件中描述。如果将 GtkConstraintLayout 添加到 UI 文件中，则可以在特殊的 “<constraints>” 元素中列出约束和引导线

  <object class="GtkConstraintLayout">
    <constraints>
      <constraint target="button1" target-attribute="width"
                     relation="eq"
                     source="button2" source-attribute="width" />
      <constraint target="button2" target-attribute="start"
                     relation="eq"
                     source="button1" source-attribute="end"
                     constant="12" />
      <constraint target="button1" target-attribute="start"
                     relation="eq"
                     source="super" source-attribute="start"
                     constant="12" />
      <constraint target="button2" target-attribute="end"
                     relation="eq"
                     source="super" source-attribute="end"
                     constant="-12"/>
    </constraints>
  </object>

您还可以使用 “<guide>” 自定义元素描述引导线

  <constraints>
    <guide min-width="100" max-width="500" />
  </constraints>

视觉格式语言

除了 XML 之外，约束还可以使用一种称为 “视觉格式语言” 的紧凑语法来描述。VFL 描述是面向行和列的：您使用一行视觉上类似于您正在实现的布局来描述布局中的每一行和每一列，例如

|-[findButton]-[findEntry(<=250)]-[findNext][findPrev]-|

描述了一个水平布局，其中 findButton 小部件与布局管理器的前导边缘分隔一些默认空间，然后是相同的默认空间量；然后是 findEntry 小部件，它旨在最多 250 像素宽。在 findEntry 小部件之后，我们再次有一些默认空间，然后是两个小部件 findNext 和 findPrev，它们彼此紧靠；最后，这两个小部件与布局管理器的尾随边缘分隔默认空间量。

使用 VFL 表示法，GtkConstraintLayout 将创建所有必需的约束，而无需手动描述它们。

重要的是要注意，VFL 不能描述所有可能的约束；在某些情况下，您将需要使用 GtkConstraint 的 API 创建它们。

约束布局的限制

约束布局非常灵活，因为它们可以实现任何布局策略。这种灵活性是有代价的

  • 您的布局可能存在过多解决方案，这使其变得模糊且不稳定；如果您的布局非常复杂，这尤其会成为问题
  • 您的布局可能没有任何解决方案。这通常发生在您没有使用足够约束条件时；一个经验法则是每个目标每个维度至少使用两个约束条件，因为所有小部件都应该具有确定的位置和大小
  • 同一个布局可以通过不同的约束系列来描述；在某些情况下，几乎不可能说哪种方法更好，这意味着您将不得不进行实验，尤其是在动态添加或删除 UI 元素，或者允许用户交互（如拖动 UI 元素）的布局方面

此外，在较大规模的情况下，本地的、临时的布局管理器可能比基于约束的布局管理器更高效；如果您的列表框可以增长到未知数量的行，除非您预先测量性能影响，否则不应将其替换为约束布局。

演示

当然，自从我们添加了这个新的 API 之后，我们还在 GTK 演示应用程序中添加了一些演示

A constraints demo
约束演示窗口，作为 GTK 演示应用程序的一部分。

以及一个完整的约束编辑器演示

The GTK constraints editor demo
GTK 约束编辑器演示应用程序的屏幕截图，左侧边栏显示 UI 元素、辅助线和约束的列表，右侧窗口显示结果

更多信息

GTK 4 中的布局管理器

自 GTK 最初开始，容器和布局策略一直是其设计的核心。如果您希望您的小部件根据特定的策略来布局其子项，则必须实现 GtkContainer 来处理子小部件的添加、删除和迭代，然后必须从 GtkWidget 实现大小协商虚函数来测量、定位和调整每个子项的大小。

GTK 4 开发周期的主要主题之一是将更多功能委托给辅助对象，而不是将其编码到 GTK 提供的基类中。例如，我们将事件处理从 GtkWidget 描述的信号处理程序转移到事件控制器，并将渲染委托给 GtkSnapshot 对象。朝着这个方向的另一个步骤是将布局机制从 GtkWidget 本身解耦到一个辅助类型 GtkLayoutManager。

布局管理器

布局管理器是负责测量和调整小部件及其子项大小的对象。每个 GtkWidget 都拥有一个 GtkLayoutManager，并使用它来代替 measure() 和 allocate() 虚函数（这些函数即将消失）。更改的要点是：不是通过子类化 GtkWidget 来实现其布局策略，而是子类化 GtkLayoutManager，然后将布局管理器分配给小部件。

就像在旧的 GtkWidget 代码中一样，您需要覆盖一个虚函数来测量布局，该函数称为 measure()，它替换了 GTK 3 的 get_preferred_* 系列虚函数

static void
layout_measure (GtkLayoutManager *layout_manager,
                GtkWidget        *widget,
                GtkOrientation    orientation,
                int               for_size,
                int              *minimum,
                int              *natural,
                int              *minimum_baseline,
                int              *natural_baseline)

测量之后，您需要将大小分配给布局；这发生在 allocate() 虚函数中，它替换了以前的 GTK 主要版本的 venerable size_allocate() 虚函数

static void
layout_allocate (GtkLayoutManager *layout_manager,
                 GtkWidget        *widget,
                 int               width,
                 int               height,
                 int               baseline)

在更深奥的一面，您还可以覆盖 get_request_mode() 虚函数，该函数允许您声明布局管理器是否请求恒定大小，或者其大小之一是否取决于相反的大小，例如高度取决于宽度或宽度取决于高度

static GtkSizeRequestMode
layout_get_request_mode (GtkLayoutManager *layout_manager,
                         GtkWidget        *widget)

您可能会注意到，每个虚函数都会传递布局管理器实例，以及正在使用该布局管理器的小部件。

当然，这对 GTK 小部件的工作方式的各个方面都有更大的影响，最明显的是布局代码的所有复杂性现在都可以限制在其自己的对象中，通常是不可派生的，而小部件可以保持可派生并变得更简单。

这项工作的另一个特点是，如果您想更改容器的布局策略，则可以在运行时更改布局管理器；您还可以拥有每个小部件的布局策略，而不会增加小部件代码的复杂性。

最后，布局管理器允许我们摆脱 GTK 的特殊情况之一，即：容器子属性。

子属性

在 GtkContainer 的内部深处，存在一个本质上是 GObject 属性相关代码的副本，其唯一的工作是为派生自 GtkContainer 的类型实现“子”属性。这些容器/子属性仅在子项被父项设置为特定容器类时才存在，并用于各种原因，但通常用于控制布局选项，例如盒子和类似盒子的容器中的打包方向；GtkFixed 内的固定定位；或笔记本选项卡小部件的展开/填充规则。

子属性很难使用，因为它们需要临时 API 而不是通常的 GObject API，因此需要在 GtkBuilder、gtk-doc 和语言绑定中进行特殊处理。子属性也附加到容器的实际直接子项，因此如果一个小部件插入了一个子项（例如，GtkScrolledWindow 或 GtkListBox 所做的那样），那么您需要保留对该子项的引用，以便更改适用于您自己的小部件的布局。

在 GTK 的主分支中，我们摆脱了它们中的大多数 - 要么只是在存在实现相同功能的实际小部件 API 时删除它们，要么创建辅助 GObject 类型并将子属性移动到这些类型。最终目标是在 GTK 4 发布时删除所有这些属性以及 GtkContainer 中的相关 API。对于与布局相关的属性，GtkLayoutManager 提供了自己的 API，以便在将子项添加到使用布局管理器的小部件或从中删除时，会自动创建和销毁对象。创建的对象是可自省的，并且在文档或绑定方面不需要特殊处理。

您从派生自己的 GtkLayoutChild 类类型开始，并像对任何其他 GObject 类型一样添加属性。然后，您覆盖 GtkLayoutManager 的 create_layout_child() 虚函数

static GtkLayoutChild *
create_layout_child (GtkLayoutManager *manager,
                     GtkWidget *container,
                     GtkWidget *child)
{
  // The simplest implementation
  return g_object_new (your_layout_child_get_type (),
                       "layout-manager", manager,
                       "child-widget", child,
                       "some-property", some_property_initial_state,
                       NULL);
}

之后，只要小部件仍是使用布局管理器的容器的子项，您就可以访问您的布局子对象；如果从父项中删除了子项，或者容器更改了布局管理器，则布局子项会自动收集。

新的布局管理器

当然，仅仅在 GTK 中拥有 GtkLayoutManager 类对我们没有任何好处。GTK 4 为应用程序和小部件开发人员引入了各种布局管理器

  • GtkBinLayout 实现了 GtkBin 的布局策略，此外还支持多个子项相互堆叠，类似于 GtkOverlay 的工作方式。您可以使用每个小部件的对齐和展开属性来控制它们在分配区域内的位置，并且 GtkBinLayout 将始终请求尽可能多的空间来分配其最大的子项。
  • GtkBoxLayout 是由 GtkBox 实现的布局策略的直接端口；GtkBox 本身已移植到内部使用 GtkBoxLayout。
  • GtkFixedLayout 是 GtkFixed 和 GtkLayout 的固定布局定位策略的端口，它增加了让您定义通用转换而不是每个子项的纯 2D 平移的功能；GtkFixed 已被修改为使用 GtkFixedLayout 并使用 2D 平移 - 而 GtkLayout 已被合并到 GtkFixed 中，因为其唯一的区别是实现了 GtkScrollable 接口。
  • GtkCustomLayout 是一个方便的布局管理器，它接受曾经是 GtkWidget 虚函数覆盖的函数，它主要用作将现有小部件移植到布局管理器未来的桥梁。

我们仍在实现 GtkGridLayout 并使 GtkGrid 在内部使用它，遵循与 GtkBoxLayout 和 GtkBox 相同的模式。GTK 内的其他小部件也将获得自己的布局管理器，但在此期间，它们可以使用 GtkCustomLayout。

最后一步是实现一个基于约束的布局管理器，它使我们能够创建复杂、响应式的用户界面，而无需将小部件打包到嵌套的层次结构中。基于约束的布局应该有自己的博客文章，敬请期待！

测试 GTK 的 Discourse

在过去的20年左右，GTK 使用 IRC 和邮件列表进行与项目相关的讨论。多年来，使用电子邮件进行通信的情况有所减少，而维护基础设施的开销却增加了；向数百或数千人发送电子邮件，在服务提供商看来，与垃圾邮件越来越难以区分，GNOME 不得不尝试请求例外情况，而这并不容易获得，而且很容易被撤销。最重要的是，用于管理邮件列表的基础设施相当老旧且不稳定，并且它被不必要地拆分为各种子类别，使得跟踪讨论比必要的更困难。

在 GTK 团队、GNOME 基础设施维护人员以及 GTK 社区的广泛讨论之后，我们决定开始试运行 Discourse 作为邮件列表的替代方案，首先，也是为 GTK 社区提供一个官方场所，用于讨论 GTK 的开发以及与 GTK 的互动，以及其他核心 GNOME 平台：GLib、Pango、GdkPixbuf 等。

您可以在 discourse.gnome.org 上找到 Discourse 实例。在其中，您可以使用 Platform 和 Core 类别来讨论关于核心 GNOME 平台的内容；您可以为您的主题使用适当的 标签，并订阅您感兴趣的标签。

我们计划将 wiki 上的一些页面也迁移到 Discourse，特别是那些我们希望从社区获得反馈的页面。

我们仍在 研究如何迁移与 GTK 相关的各种邮件列表的用户，以便关闭列表并拥有一个单一的场所，而不是分裂社区；同时，如果您订阅了一个或多个以下列表

  • gtk-devel-list
  • gtk-app-devel-list
  • gtk-list
  • gtk-i18n-list

那么您可能想看看 Discourse，并加入那里的讨论。

布鲁塞尔 GTK 黑客节的报告

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

黑客节的主要议题是

  • 回顾过去 6-12 个月内合并到 master 分支的工作，以便每个人都保持同步
  • 讨论仍在单独分支中进行的功能，评估其完成状态，并确定障碍
  • 找出 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 中删除了“plus”。 ;-)