一些核心 GTK 开发人员最近聚在一起工作了几天，讨论了当前和未来的计划。
在博文中总结三天的讨论是困难的，但以下是一些重点。
图标主题
GtkIconTheme 代码已经存在很长时间了。它实现了图标主题规范，并且源于我们使用桌面发布大型图标集并且主题需要切换它们的时代。这并不是今天图标的制作或使用方式。
我们需要一个更好的解决方案，从设计师在图纸中制作一组图标到开发人员将单个图标复制到他们的应用程序中的工作流程。
在 GTK 内部，这将需要某种形式的“资源管理器”来维护从图标名称到图像/文件/资源的映射。
语言
虽然我们无法摆脱为所有语言绑定提供带有 gobject-introspection 元数据的 C 接口，但使用比 C 更具表现力的语言和更强大的编译器可能会更好。
当然，我们不能也不会用不同的语言重写所有 GTK。尝试替换较小的部分会很好。允许用不同的语言编写新代码也可能吸引新的贡献者。
输入
我们讨论了滚动速度问题，并决定在问题中写一个解释性注释，说明我们认为正确的解决方案
- 分别处理滚轮和触摸板滚动
- 将配置从控制中心/合成器注入到 libinput
- gtk 通过事件获取它
我们讨论的另一个重大输入问题是“异步事件处理”及其问题。出现这种情况的两个主要案例是 webkit（带有其 ui<>web 进程通信）和 IBus。在这两种情况下，我们认为实际上没有兴趣将未处理的事件重新注入到 GTK 捕获/冒泡传播中。相反，这种剩余的事件应该只是“本地”处理（在 IBus 情况下，向条目添加/删除字符或移动光标）。
平台库
使用 GTK4，我们有意改变了将所有内容都放在 GTK 本身中的做法，而是引入了诸如 libadwaita 之类的“平台库”的概念，以携带更多特定于平台的窗口小部件。
总的来说，我们对结果感到满意，我们希望继续这种方法。也许有空间将一些比窗口小部件更像管道的东西移回 GTK 本身。
GTK5？
我们需要打开一个 .90 分支来执行会破坏我们现在已弃用的 API 的操作（例如文件选择器，以及更通用的选择器对话框/窗口小部件拆分）。我们中的一些人一直在渴望开始这项工作。但是 4.x 中仍然有很多工作要做（例如，GtkListView 修复）。
考虑到计划在 4.12 中实现的颜色管理工作，建议在 4.12 之后打开 4.90 开发分支。这将使其在今年年底，并且在 4.0 发布 3 年后，这看起来是合理的。
结束
最后一天，我们很高兴在我们的场地接待了文档和跟踪团队。
一个房间里的三个黑客马拉松！
我们要感谢 GNOME 基金会对我们会议的支持。❤️