GTK 4.4

GTK 4.4.0 现在可以在通常的地方下载。以下是其中一些重要工作内容。

NGL 渲染器和 GL 支持

NGL 渲染器持续改进。这包括速度提升、变换渲染的修复、避免巨大的中间纹理以及正确处理部分颜色字体。在驱动程序开发人员的一些帮助下,NGL 现在可以与 Mali 驱动程序正确工作。我们计划在下一个周期中删除原始的 GL 渲染器。

在 GSK 之外,我们的 OpenGL 设置代码已经清理和简化。我们越来越依赖 EGL,现在需要 EGL 1.4。在 X11 上,我们使用 EGL,如果需要则回退到 GLX。在 Windows 上,我们默认使用 WGL。

我们的 GL 支持可以与最新的 NVidia 驱动程序完美配合。

主题

包含的主题已重新组织和重命名。我们现在发布的主题名为 Default、Default-dark、Default-hc 和 Default-hc-dark。Adwaita 主题正在迁移到 libadwaita。

较小的主题改进包括新的错误下划线(现在是虚线而不是波浪线)以及对半透明文本选择的支持。

输入

输入处理在本周期中得到了积极的开发。我们将内置输入法的行为与 IBus 相匹配,以显示和处理组合序列和死键。作为其中的一部分,我们现在支持多个死键和不产生单个 Unicode 字符的死键组合(例如 ẅ)。

我们现在完全支持 32 位键码,因此使用 Unicode 键码(例如用于组合标记)可以正常工作。

表情符号

我们的表情符号数据已更新为 CLDR 39,我们正在寻找按语言和地区(例如 it-ch)翻译的表情符号数据。

调试

检查器现在默认启用,因此调试 GTK 应用程序应该会更容易一些。

Windows

除了前面已经提到的 WGL 改进之外,我们现在在 Windows 上使用 GL 进行媒体播放。4.4 中后期的一个重大变化是,我们现在为平板电脑和其他输入设备使用 WinPointer API,取代了过时的 wintab API。Windows 上的 DND 支持也得到了改进,并且本地 DND 协议已删除。

数字

GTK 4.4 是 5 个月开发的成果,共有 71 位开发人员提交了 838 次单独的提交;总共添加了 88133 行代码,删除了 63094 行代码。

提交变更集最多的开发人员
Matthias Clasen 456 54.4%
Benjamin Otte 82 9.8%
Emmanuele Bassi 48 5.7%
Alexander Mikhaylenko 35 4.2%
Chun-wei Fan 30 3.6%
Christian Hergert 18 2.1%
Luca Bacci 17 2.0%
Carlos Garnacho 10 1.2%
Bilal Elmoussaoui 10 1.2%
Florian Müllner 7 0.8%
Yuri Chornoivan 6 0.7%
Maximiliano Sandoval R 6 0.7%
Marc-André Lureau 5 0.6%
Marco Trevisan (Treviño) 5 0.6%
Pawan Chitrakar 5 0.6%
Piotr Drąg 4 0.5%
Timm Bäder 4 0.5%
Xavier Claessens 4 0.5%
Zhi 4 0.5%
Sebastian Cherek 4 0.5%

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 参考

GTK3ATK 的 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 中的文本输入

为了总结最近关于输入主题的一系列帖子,让我们来谈谈 GTK 4 中的文本编辑。

简单:快捷方式

也许您只需要将一些键作为编辑命令处理,例如 Ctrl-z 来撤消。在这种情况下,您只需使用带有操作的快捷方式,并在您的 widget class_init 中进行设置即可

/* install an undo action */ 
gtk_widget_class_install_action (widget_class,
                                  "text.undo", NULL,
                                  my_undo_func);

/* bind Ctrl-z to the undo action */
 gtk_widget_class_add_binding_action (widget_class,
                                      GDK_KEY_z, GDK_CONTROL_MASK,
                                      "text.undo", NULL);

复杂:文本编辑器

当您需要完整的文本编辑时,最佳方法是重用 GTK 中为此目的预先制作的小部件之一:其中一个条目,或者如果您需要完整的文本编辑器,则使用 GtkTextView。

如果现有的条目都不适合您的用例,您也可以将您自己的 GtkEditable 实现包装在 GtkText 小部件周围,并免费获得文本编辑小部件的所有困难部分。GTK 文档解释了如何做到这一点。

中间地带

但是,如果您不想要一个条目,但仍然需要让您的用户方便地输入单个 Unicode 字符,例如 ñ 或 Å,该怎么办?我会让您为此提出一个用例(尽管我脑海中有一个用例)。

你可以做的一件事是直接使用 GtkIMContext,并让它为你处理按键事件。其工作方式是将一个按键事件控制器附加到你的部件,并将一个输入法上下文连接到它。

controller = gtk_event_controller_key_new ();
gtk_widget_add_controller (widget, controller);

im_context = gtk_im_multicontext_new ();
gtk_event_controller_key_set_im_context (controller, im_context);

现在,到达你部件的按键事件将被传递到输入法上下文。连接一个处理程序到它的 ::commit 信号,以接收完成的输入。

static void
commit_cb (GtkIMContext *context,
           const char   *str,
           DemoWidget   *demo)
{
  pango_layout_set_text (demo->layout, str, -1);
  pango_layout_set_attributes (demo->layout, NULL);
  gtk_widget_queue_draw (GTK_WIDGET (demo));
}

...

g_signal_connect (im_context, "commit",
                  G_CALLBACK (commit_cb), demo);

你可以连接一个类似的处理程序到 ::preedit-changed 信号,以便在预编辑期间为用户提供像 GtkEntry 那样的反馈。

单字符输入的完整示例可以在这里找到。

更多关于输入

我之前写过关于输入的文章 (这里这里),最近,Carlos 和我一起在 Guadec 上做了一个关于输入相关主题的演讲 (幻灯片)。在那些文章中,我解释了死键是如何工作的,以及你如何输入

<dead_acute> A

来产生一个 Á 字符。

但是输入充满了惊喜,我刚刚了解了死键的一种替代方案,值得在这里介绍一下。

背景

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

我们收到第一个按键事件,并注意到它是一个死键,所以我们把它存储在所谓的预编辑中,并等待下一个事件。当下一个键到达时,并且它代表一个字母(更准确地说,属于 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+’ 来获得一个顶部带有 ´ 的 Â。太棒了!