谁编写了 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 小部件
  • GtkNativeGtkRoot 接口
  • 每个小部件的操作
  • 简化的 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 的第一个真正的 beta 版。

 

开发人员

按提交次数排名前 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 都超越了其他所有贡献者。

雇主

按提交次数
Red Hat 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%)
Intel 6 (0.0%)
Novell 3 (0.0%)
按更改次数
Red Hat 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%)
Intel 222 (0.0%)
Collabora 208 (0.0%)
Endless 121 (0.0%)
按贡献者
(未知) 199 (72.4%)
GNOME 32 (11.6%)
Red Hat 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%)
Intel 1 (0.4%)
Purism 1 (0.4%)

虽然 Red Hat 员工贡献了最多的更改,但我们仍然有大量来自社区的贡献者——他们既使用自己的 GNOME 电子邮件地址,也使用自己的工作地址,即使是在个人层面做出贡献时也是如此。我们还有来自 GNOME 和大型自由软件生态系统中各个公司的多位贡献者,这表明该项目周围有一个健康的社区。

与 GTK3 比较数字 比较棘手

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

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

¹ – GNOME 基金会的受薪员工。

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

构建和测试 GTK

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

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

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

现在,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 上,针对 Fedora 和 Debian 当前稳定版本的静态和共享库工件,进行完整的 Meson 调试构建
  • 在 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 存储库