关于输入的更多内容

我之前写过关于输入的内容（这里 和 这里），最近，Carlos 和我还在 Guadec 上就输入相关主题做了一个演讲（幻灯片）。在这些文章中，我解释了死键的工作原理，以及如何输入

<dead_acute> A

以产生 Á 字符。

但输入充满了惊喜，我刚刚了解了一种替代死键的方法，值得在此介绍。

背景

首先，让我们回顾一下当您向 GTK 发送 <dead_acute> A 序列时会发生什么。

我们收到第一个按键事件，并注意到它是一个死键，因此我们将其存储在我们所谓的预编辑中，并等待下一个事件。当下一个键到达，并且它表示一个字母（更准确地说，是在 Unicode 类别 Ll、Lu、Lt、Lm 或 Lo 之一中）时，我们查找与 dead_acute 匹配的 Unicode 组合标记，即 U+301 组合锐音符，然后我们将序列翻转。因此，提交的文本是

A <combining acute>

我们必须翻转的原因是，组合标记位于基本字符之后，而死键位于基本字符之前。

这可行，但对于编写多重音字符来说有点不直观。您必须从上到下考虑要应用的重音，因为它们会向后应用。例如，要创建一个顶部带有锐音符的 Â，您需要输入

<dead_acute> <dead_circumflex> A

然后将其翻转，最终变为

A <combinining circumflex> <combining acute>

更好的方法

对我来说，按照这样的顺序指定重音感觉更自然

  1. 给我一个 A
  2. 然后在顶部放一个 ^
  3. 然后在顶部放一个 ´

好消息是：我们可以做到！键盘布局可以使用任何 Unicode 字符作为键码，因此我们可以直接使用组合标记，而无需通过死键绕道。

例如，“英语（美国，国际，AltGr Unicode 组合）”布局包含组合标记的键。使用此布局的一个小障碍是它默认不会显示在 GNOME 设置键盘面板中。您必须运行

gsettings set org.gnome.desktop.input-sources show-all-sources true

使其显示出来。

此布局中的组合标记放置在“第 3 级”中。要使用它们，您需要设置一个“第 3 级选择器”键。在键盘面板中，这称为“替代字符键”。常见的选择是右 Alt 键。

完成所有这些准备工作后，您现在可以输入 A Alt+^ Alt+’ 以获得顶部带有 ́ 的 Â 。太棒了！

图形 API 探险

许多人正在努力将桌面虚拟化 UI 移植到 GTK4。这通常涉及 virgl，而 GTK3 的解决方案是使用 GtkGLArea。

对于 GTK4，渲染无论如何都在 GL 中进行，因此只需将您的内容包装在 GdkTexture 中，然后将其交给 GTK 即可，无论是将其用作带有 GtkPicture 的可绘制对象，还是在您自己的 snapshot() 实现中使用 GskTextureNode。

dmabuf 绕道

这是一个不错的理论，但实践更为复杂 – 内容通常以 dmabuf 对象的形式提供，而对于 4k 渲染，如果您可以避免额外的复制，那么您真的应该这样做。因此，我们必须研究将 dmabufs 作为纹理导入 GL 而无需复制的可用解决方案。

这变成了一次图形 API 迷宫的快速之旅：OpenGL、EGL、GL ES、GLX、DRI，……清单不胜枚举。最后，事实证明，您可以使用 EGL 将 dmabuf 包装到 EGLImage 中，并使用 GL_OES_EGL_image 扩展从中创建 GL 纹理。

GLX 到 EGL

这在我们的 Wayland 后端（使用 EGL）中运行良好。不幸的是，我们更旧的 X11 后端有一个使用 GLX 的 GL 实现，并且似乎没有办法将 dmabuf 导入到 GLX 上下文中。

因此，我们不得不做一些额外的工作，并使我们的 X11 后端也使用 EGL。值得庆幸的是，Emmanuele 几年前有一个未完成的分支，其中包含这样一个转换，可以正常工作（在最初抓头皮，搞不懂为什么它不渲染任何东西之后 – 在进行 GL 工作时总是这样）。

解决方案

事实证明，使用 EGL 导入 dmabufs 可以很好地在 GTK 外部完成，因此我们不需要为其添加特定于 Linux 的 API。为了省去您自己编写此类代码的麻烦，这里 是我提出的内容。

在我们已经决定将 X11 后端移植到 EGL 之后，我了解到导入 dmabufs 的另一种可能性可能是使用 DRI3PixmapFromBuffer 从 dmabuf 创建 X11 像素映射，将其转换为 GLXPixmap，并使用 glxBindTexImageEXT 创建纹理。

图形 API 真棒！:-)

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-Introspection 为语言绑定公开了一个完整的 API 以供使用。新文档使用相同的数据，这不仅使我们可以将构建时间缩短一半，而且还可以从源代码中的注释生成常见的文档位，从而使 API 参考更加一致和可靠；最后，C API 参考与语言绑定作者在使用内省数据时看到的内容相匹配，这意味着我们将在引入新 API 时加强工具包和绑定开发人员之间的反馈循环。

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

杂项

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

  • 全面性能提升，从用于渲染内容的 GLSL 着色器，到按需创建而非预先创建的可访问性对象。
  • 当使用较新版本的 Cairo 和适当的 API 时，实现文本的亚像素定位。
  • 表情符号选择器的响应式布局。
  • 改进了弹出窗口小部件中阴影的渲染效果。
  • 微调按钮中的本地化数字。
  • 改进了对 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%

输入，再次审视

我上次的更新谈到了 GTK 输入法中组合序列的更好视觉反馈。当时我没有明确提及死键，但从历史上看，X11 对待死键和组合序列的方式完全相同。

死键是某些键盘布局的一个特性，你可以按下一个键，它本身不会产生字符，而是修改你键入的下一个键。通常，这用于可以与不同基本字符组合的重音符号。例如，键入 <dead_acute> <a> 来产生 á，或键入 <dead_acute> <o> 来产生 ó。

传统上，死键是真正的死的——在最终结果出现之前，你不会得到任何视觉反馈。通过上次更新中描述的改进，我们现在在输入时显示死键

这是一个不错的改进。但事实证明，并非所有人都满意。

对组合序列和死键的共享处理有一些影响：其中一个影响是，输入一个不存在的序列，如 <dead_grave> <x>，会产生蜂鸣声，并且没有输出。对于你使用组合键显式启动的组合序列来说，这是可以接受的，但是当你可能只是想输入 `x 时，就没那么好了。

那些决定使用组合序列来表示死键的人预见到了偶尔需要实际输入空格重音符的需求，并添加了诸如 <dead_grave> <space> 和 <dead_grave> <dead_grave> 等序列来产生一个 ` 字符。

虽然这是一个不错的想法，但仍然很不方便，因为你需要键入 <dead_grave> 六次来产生 `‍`‍`，例如，在 markdown 中输入代码示例。

在考虑了一段时间并比较了其他系统的做法之后，我们做出了两个更改，希望这将使死键的使用像键盘上的任何其他键一样方便。

  • 当 <dead key> <key> 序列与我们的任何组合序列不匹配时，提交各个键
  • 当一个 <dead key> 跟随另一个 <dead key> 时，提交第一个，并将第二个视为新组合序列的开始

总而言之，这使得键入 <dead_acute> <a> 产生 á，键入 <dead_grave> <x> 产生 `x，你只需要键入 <dead_grave> 三次即可输入 `‍`‍`:

好多了！

GTK 近况

GTK 4.2 计划于 3 月发布——它不会是一个巨大的版本，只有增量改进。但是，除了通常的错误修复和性能改进之外，还有一些值得单独强调的内容。

新的 GL 渲染器

Christian Hergert 一直在努力工作，为 GTK 创建一个新的 GL 渲染器。这项工作的最初动机是希望提高我们在 MacOS 上的渲染性能，因为在 MacOS 上，GL 驱动程序不如在 Linux 上那么宽容。除此之外，从头开始使用新的渲染器，我们有机会应用在当前 GL 渲染器上工作时学到的所有知识，并重新组织代码以实现未来的改进，例如重新排序和批处理绘制命令。

新的渲染器尚未合并，但它正在接近功能对等，很可能进入 4.2 版本。我们可能会同时包含旧的和新的渲染器，至少一段时间内是这样。

弹出窗口阴影

自从引入 GtkPopover 及其标志性的“喙”以来，弹出窗口已经裁剪了其边界之外的所有内容，因为我们需要喙的尖端始终如一地放置。使用 GTK4 中基于新的 xdg-popup 的实现，我们有了一个表达能力足以放置弹出窗口的定位协议，该协议可以在使“喙”指向其应该指向的位置的同时，允许在弹出窗口下方和周围显示阴影。与窗口阴影一样，弹出窗口阴影位于输入区域之外，因此单击会传递到底层窗口。

这是一件小事，但它可能会在赋予 UI 深度和结构方面产生明显的影响。

更好的输入

GtkIMContextSimple 是内置于 GTK 中的输入法实现。当我们没有平台方法可用时，例如 Wayland 文本协议，就会使用它。GtkIMContextSimple 只做几件事。其中之一是用 Control-Shift-u 解释 Unicode 字符的十六进制输入。另一个是它处理组合序列，例如

<Compose Key> <a> <acute>

输入一个 á 字符。

大多数组合序列都以该组合键开头，GNOME 40 中的键盘设置将包含一种将键盘上的键分配给此功能的方法。

在 GTK 方面，我们已经解决了关于组合序列支持的一些长期抱怨。除了其内置序列之外，GTK 还会解析 X11 组合文件。这些文件的格式在 Compose(5) 中描述，但直到现在，GTK 对此格式的支持还很不完整。使用 GTK 4.2，我们正在改进这一点，以便

  • 允许最多 20 个按键的序列（之前限制为 7 个）
  • 生成多个字符（特别是，这允许 Unicode 表情符号序列）
  • 支持十六进制码位

这些对于那些通过编辑 ~/.Compose 来创建自己的 Compose 序列的人来说是很不错的改进。但是我们其他人呢？使用 Compose 序列一个传统上困难的地方在于你必须牢记这些序列，并且盲打它们。在序列完成并且最终字符出现之前，没有任何视觉反馈。不久前，IBus 通过将不完整序列的字符显示为带下划线的预编辑文本来改进了这一点，类似于我们对十六进制 Unicode 输入所做的操作。

在为 GTK 复制他们的方法后，最初的用户反馈褒贬不一，主要是因为 Compose 键的官方符号 (⎄) 在意外出现时有点分散注意力。因此，我回到了绘图板，并提出了不同的方法

我希望这能更好地工作。欢迎反馈！

所有这些输入更改也将出现在 GTK 3.24.26 中。

GTK 4.0.1

我们在 4.0 版本之后都休息了一段时间，做了一些其他的事情，但现在是 GTK 4.0.1 的时候了。

这是 4.0 之后的第一个版本，它自然包含了很多小的错误修复、主题和文档改进等等。但是有一些值得指出的亮点。

更好的媒体支持

此版本中较大的进展之一：我们设法使 gstreamer 媒体后端使用 GL 纹理，这避免了在使用硬件加速进行解码（如 vaapi）时在 GPU 和 CPU 之间来回传递帧数据。这需要仔细地协调以弥合 gstreamer 和 GTK 处理 GL 的方式差异，但我们设法在许多情况下使其工作。

这是否意味着 GtkVideo 现在已准备好支持功能齐全的媒体播放器应用程序？远非如此。它仍然只允许你播放来自文件或 URL 的媒体，并且不支持多声道音频、视频叠加、设备选择、输入以及你在媒体播放器中可能需要的其他功能。

如果有人将 GTK 媒体后端中的代码翻转过来，制作一个 GStreamer 插件，其 sink 将其视频帧作为 GdkPaintable 公开，那将非常好。这将允许你使用 gstreamer API 来获得上述所有功能，同时仍然可以顺利地集成到 GTK 中。

更好的 CI

为了保持我们新的 MacOS 后端的正常工作，我们已经开始为此平台设置 CI 构建，包括 GTK 本身，及其依赖项（pango，gdk-pixbuf）。

谁编写了 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 的第一个真正的 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 在提交次数和代码更改方面都远远超过其他所有贡献者。

雇主

按提交
红帽 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%)
通过更改
红帽 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%)
红帽 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 4.0

2020 年是很漫长的一年。有什么比发布一个主要版本更好的方式来结束它呢！今天，我们发布了 GTK 4.0。

GTK 4.0 是由一支敬业的开发人员小团队努力工作的成果。我们将单独发布一篇帖子来回顾统计数据，但简短的总结是，自 2016 年 11 月发布的 3.89.1 版本以来，我们添加了超过 18000 个提交，并发布了超过 20 个开发版本。

祝贺并非常感谢所有参与这项工作的人，特别是 Benjamin、Emmanuele、Timm、Carlos、Jonas 和 Christian！

新增功能

不可能在一篇文章中总结 4 年的开发工作。在过去的一年中，我们撰写了关于此版本中许多新事物的详细文章：数据传输、事件控制器、布局管理器、渲染节点、媒体播放、可缩放列表、着色器、辅助功能。以下是一些亮点，以可视化形式呈现

媒体播放

拖放

布局管理器和变换

可缩放列表和网格

着色器

旧的功能

GTK 4 现在稳定了，我们认为它已经可以投入使用了。这并不意味着 GTK 3 已经死了——我们将在可预见的未来继续支持和更新它（最新版本 3.24.24 几天前悄悄发布了）。然而，这确实意味着 GTK 2 已经走到了生命的尽头。我们将在未来几天发布最终的 2.x 版本，我们鼓励大家将他们的 GTK 2 应用程序移植到 GTK 3 或 4。

如何获取

源 tar 包在通常的位置可用。二进制包应该很快就会出现在主要的发行版中。

GNOME 40 版本将有许多应用程序移植到 GTK 4。如果您今天想尝试 GTK 4.0，可以使用 gtk4-demo 和 gtk4-widget-factory 的每晚 flatpak 构建版本

$ flatpak install https://nightly.gnome.org/repo/appstream/org.gtk.Demo4.flatpakref
$ flatpak run org.gtk.Demo4

如果您急于将应用程序移植到 GTK 4，我们的迁移指南可用，作为文档的一部分。

如何支持 GTK

如果没有许多志愿者贡献错误报告、补丁、翻译或想法，GTK 就无法开发。感谢你们所有人。我们还要感谢 GNOME 基金会为 GTK 提供开发资源、基础设施和旅行援助。

向 GNOME 基金会捐款是支持未来 GTK 开发的好方法。

接下来是什么

我们非常感谢所有早期测试人员为我们提供了错误报告和反馈，这使得此版本更好。但我们完全预计将很快发布 4.0.1 版本，以修复只有在 .0 版本发布后才会出现的疏忽和陷阱。

现在我们有了 4.0 版本，我们需要引入库生态系统，以使应用程序能够使用它。vte、webkit 和 gtksourceview 是通常与 GTK 一起使用的一些最著名的库。我们预计这些库的 GTK 4 端口很快就会推出。

如果出现更严重的问题，我们将在 GNOME 40 发布时发布 4.2 版本，否则我们可能会等到夏天再发布。

GTK 4 之后的未来会带来什么仍有待观察。我们有一些有趣的事情正在进行中，但我们也想听听应用程序开发人员希望在 GTK 中看到哪些功能。告诉我们！

庆祝活动

我们将在本周五通过（在线）聚会来庆祝 4.0 版本的发布。欢迎随时加入！

GTK 4 中的辅助功能

上周 GTK 3.99.3 版本中的重大新闻是，我们为新的辅助功能实现提供了一个首个非平凡的后端。因此，现在是深入了解 GTK 4 中的辅助功能的好时机。

概述

让我们快速回顾一下辅助功能在 Linux 上的工作方式。其中的参与者是应用程序和辅助技术 (AT)，如屏幕阅读器（例如，Orca）、放大镜等。

AT 的目的通常是为用户提供与应用程序交互的替代方式，这些方式是根据他们的需求量身定制的（例如，放大的视图、大声朗读的文本或语音命令）。为此，AT 需要大量关于应用程序 UI 的详细信息，这就是辅助功能堆栈发挥作用的地方——它是应用程序（或其工具包）和 AT 之间的连接层。

应用程序和 AT 在辅助功能总线上相互通信，该总线是 D-Bus 会话总线的单独实例，使用 AT-SPI 项目描述的接口。应用程序的 UI 元素在总线上表示为对象，这些对象实现了一些抽象接口，例如 Text 或 Value。应用程序发出信号以传达 UI 中的更改，AT 可以调用对象上的方法来获取信息或进行更改（例如，更改 Value 接口的当前值以移动它所代表的 GtkScale）。

发生了什么变化

在 GTK 2 和 3 中，这是以一种笨拙的间接方式完成的：GTK 小部件具有辅助可访问对象，这些对象是 ATK 接口的实现（转换 1：GTK ➙ ATK）。然后，这些对象在 at-spi2-atk 中的适配器代码中转换为 AT-SPI 对象（转换 2：ATK ➙ AT-SPI），这些对象在辅助功能总线上表示。另一方面，AT 然后使用 pyatspi 将 AT-SPI 接口转换为 Python 对象（转换 3：AT-SPI ➙ Python）。

这个多步骤过程效率低下、有损且难以维护；它需要在至少三个组件上实现相同的功能，并且导致记录的 AT-SPI 方法和属性与实际通过辅助功能总线发送的方法和属性之间存在差异。

在 GTK 4 中，我们通过删除 ATK 和 at-spi2-atk 来简化应用程序端。小部件现在实现了一个 GtkAccessible 接口，该接口允许它们设置许多角色、状态、属性和关系，这些角色、状态、属性和关系或多或少直接取自 W3C 发布的 WAI-ARIA 规范。GTK 辅助功能 API 的 AT-SPI 后端然后采用这些受 ARIA 启发的属性（以及小部件本身的知识），并将小部件表示为辅助功能总线上的对象，从而为它们实现相关的 AT-SPI 接口。

这是一种更直接的方法，并且与 Qt 和 Web 浏览器已经做的事情相匹配。

应用程序 API

以下是您在应用程序中使用 GTK 4 时最有可能遇到的辅助功能 API 的亮点

设置可访问角色。角色是对小部件语义的描述，AT 将使用它来决定应向其用户呈现什么样的行为。设置角色是一次性操作，这意味着它必须在小部件创建时完成，无论是在 class_init 中还是在实例初始化期间完成

gtk_widget_class_set_accessible_role (widget_class,  
                                      GTK_ACCESSIBLE_ROLE_BUTTON);

更新小部件的可访问状态或属性。每当小部件的可访问表示发生更改时，都应执行此操作

gtk_accessible_update_property (GTK_ACCESSIBLE (widget),
                       GTK_ACCESSIBLE_PROPERTY_VALUE_MIN, minimum,
                       GTK_ACCESSIBLE_PROPERTY_VALUE_NOW, value,
                       GTK_ACCESSIBLE_PROPERTY_VALUE_MAX, maximum,
                       -1);

GTK 参考文档提供了辅助功能 API 的概述，其中包括针对应用程序开发人员和小部件编写者的指南。

接下来是什么？

对于 GTK 4.0，我们专注于完成 AT-SPI 后端。但是，有了新的 API 和后端分离，我们有了一条清晰的道路，可以为其他平台制作辅助功能后端，这是我们希望在后续 GTK 4 版本中研究的。

在 Linux 上，我们希望与其他利益相关者合作，对 AT-SPI 接口进行现代化改造，以最终克服在某些地方仍然可见的 CORBA 遗留问题。其中一部分是将从辅助功能总线转向应用程序和辅助技术（AT）之间的点对点连接；这将增强辅助功能堆栈的安全性，并堵住 Flatpak 等技术使用的沙箱中的漏洞。

未来，我们希望引入工具，以确保应用程序开发人员能够意识到缺失的辅助功能注释，例如为 UI 中的图标和图像提供标签属性或 labelled-by 关系；或者确保每个 UI 元素都在可访问树中正确表示。我们已经为 GtkAccessible 接口准备了一个测试后端，可以用来编写单元测试，并验证角色和属性在必要时是否已更新。

GTK 3.99.2

GTK 3.99.2 版本延续了 3.99.1 中的主题：api 清理、新的和改进的演示、更好的文档。您可以在这里查看详细信息。

关于文档主题的一个小提示是，我们依赖于一些未发布的 gtk-doc 功能。因此，我们现在将 gtk-doc 作为子项目包含在 gtk 发布 tarball 中。如果您是发行商，请不要惊讶于构建 GTK 现在会安装 gtk-doc 工具。

这个快照中的重大新闻是我们致力于更多地展示新的基于 GL 的渲染堆栈的功能。

热身：Shadertoy

gtk4-demo 现在包含一个 Shadertoy 演示。

该演示使用 GtkGLArea 小部件来运行与 shadertoy.com 上的片段兼容的 GLSL 代码。如果您将这些示例粘贴到此演示的编辑器中，那么许多示例都可以正常工作。

这很有趣，但在某种程度上是有限的。GLSL 被限制在它的“沙箱”中，即使用 GL api 来编译和使用着色器的 GtkGLArea 小部件。

着色器作为一等对象

这不是我们第一次尝试制作一个类似 Shadertoy 的东西。当我们第一次考虑它时，我们认为我们会创建一个应用程序可以使用的着色器抽象。当发现使其跨不同的渲染器和后端工作需要我们编写自己的着色器编译器时，我们把它放在了一边——工作量太大了。

但在我们 Shadertoy 成功之后，我们重新审视了将着色器作为一等对象的想法，并设定了更适度的目标：我们使用 GLSL，并且不尝试让着色器与 OpenGL 渲染器以外的任何东西一起工作。

在 3.99.2 中，我们现在有了

有了这些组件，我们制作了一个演示，展示了着色器的各种用途。它可能有点过载，并且某些效果有点过分，但它表达了重点：您可以在您的小部件中使用着色器。

 

我们尚未做的是添加内置着色器支持的小部件。该演示展示了一些可能的候选对象

一个着色器可绘制对象。您可能 还记得，GdkPaintable 是任何可以“绘制”的东西的非常灵活的接口。着色器当然符合条件。gtk-demo 中的 GskShaderPaintable 使用没有输入纹理的着色器来生成像素，我们将其添加到 GtkPicture 小部件中，使其出现在小部件树中。

一个着色器容器。这是一个非常简单的 容器，可以使用着色器在子小部件的顶部绘制效果。它适用于需要单个输入纹理（用于子小部件）的着色器。

一个着色器堆栈。这是一个类似堆栈的 容器，显示多个子小部件之一，并在可见子小部件更改时使用着色器进行过渡。它适用于需要两个输入纹理（用于旧的和新的活动子小部件）的着色器。

值得庆幸的是，在 GTK 4 中制作自定义小部件比过去容易得多，因此渲染节点 API 应该足以让您开始进行一些有趣的实验。您当然可以将 gtk4-demo 代码作为起点。

您可以调试它

除了小部件之外，着色器支持是完全集成的。GTK 检查器可以像任何其他渲染节点一样处理着色器节点，您可以序列化它们，例如在 gtk4-node-editor 中加载生成的文件

如果您需要查看 GTK 发送到着色器编译器 的输入，设置环境变量

GDK_DEBUG=shaders

可能会有所帮助。

下一步是什么？

在这次 GL 冒险之后，我们现在将专注于推出更多新的辅助功能基础设施。