标签: 社区

谁编写了 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 黑客节 2020 — 路线图和辅助功能

1 月 28 日至 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 中的数据）。这似乎没有争议；Robert 将会实现它。
  • 一个有序的映射。这在许多地方通过将哈希表与列表或数组组合起来进行临时实现。似乎大家一致认为，如果在 GLib 中提供这个功能是值得的，如果有人做一些工作来提出一个 API

关于有序映射的讨论也涉及到了通用容器接口；Philipp 描述了如何做到这一点，详情请参见 此处。

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

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

暗黑模式

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

有各种选择

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

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

GTK

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

  • 一个可缩放的列表视图，可以回收行小部件。这包括在更多地方更广泛地切换到使用列表模型。为了使它完整，它还应该包括一个使用该技术的网格视图。Benjamin 正在研究这个。
  • 用于动画的基础设施和 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 测试 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 个月内合并到主分支的工作，以便每个人都了解情况
  • 讨论仍在单独分支中进行的特性，评估它们的完成状态，并找出阻碍因素
  • 找出 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 的报告

在 Guadec 的 BoF 期间，GTK+ 团队进行了一整天的计划会议，我们坐满了整个房间，其中还包括来自几个下游的代表，而不仅仅是 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+ 主分支中 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 应用程序开发人员可以将他们的主分支切换到 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 机制。