GTK 开发博客

我们上一篇关于 GTK4 中无障碍功能的帖子是 一段时间之前了，是时候更新一下了。

感谢 Red Hat 的 Lukáš Tyrychtr 现在正在致力于无障碍功能。

无障碍功能 – 如何工作？

从 GTK3 到 GTK4，无障碍功能方面最大的变化之一是我们有了一个新的应用程序 API，该 API 仿照了 Web 上的 ARIA 规范。

要记住的高层视图是

app → ARIA → AT-SPI → accessibility bus → AT

这里的 AT 代表无障碍技术。在实践中，这主要意味着 orca，这是一个著名的屏幕阅读器（尽管有一个新的竞争者，即 odilia 项目）。

新层提供了诸如

void gtk_accessible_update_state (GtkAccessible *self,
                                  GtkAccessibleState first_state,
                                  ...)

之类的 API，允许应用程序设置其小部件的可访问属性。

ARIA 层改进

自从我们在 GTK4 中引入它以来，应用程序 API 层只经历了适度的更改。自从 Lukáš 开始致力于此以来，大约在过去的 9 个月中，这种情况开始发生变化。

他开始做的一件事是添加公共接口，以便第三方小部件（例如 libadwaita）可以提供完整的无障碍功能支持。第一个这样的接口是 GtkAccessibleRange（4.10 版本中的新功能），用于诸如 GtkScale 之类的范围小部件。我们正在考虑添加更多功能，特别是 文本接口。这将是使终端可访问所必需的。

在 4.12 版本中，我们做了一些工作，使我们的实现更接近 ARIA 规范。这涉及到更改一些小部件的角色：我们的默认角色现在是“通用”，而顶层窗口使用“应用程序”角色。我们还重新调整了可访问名称和描述（即您听到 orca 读取的内容）的计算方式，以匹配 规范。

另一个改进是，我们的大多数小部件现在都具有必要的标签和关系，以使 orca 可以读取它们。如果您发现仍然缺少某些内容，请告诉我们！

AT-SPI 转换改进

我们希望看到对 AT-SPI D-Bus API 进行一些现代化改造，这已不是什么秘密。但目前，我们必须使用它。我们的转换层通过仅将 AT 请求的对象延迟放置在总线上来工作，以避免产生过多的总线流量。

我们转换的最新改进之一是我们现在正在使用 GtkAccessibleRange，因此第三方范围小部件可以访问。

我们还修复了 GtkNotebook 和 GtkStackSwitcher 的选择实现的问题，因此 AT 现在可以在笔记本和堆栈中更改选定的选项卡。

工具

所有这些听起来都不错，但是如果您是应用程序开发人员，您可能想知道如何查找和修复应用程序中的无障碍功能问题。

只需打开屏幕阅读器并查看它在您浏览应用程序时所说的内容是非常有益的。但是我们也有一些工具可以帮助您评估应用程序的无障碍功能支持。

GTK 检查器有一个页面显示无障碍功能信息

最近对其进行了改进，不仅显示了在每个小部件上设置的属性、状态和关系，还显示了 GTK 计算并传递给 AT 的名称和描述 - 即 orca 读取的文本。

检查器中的另一个工具是全新的：无障碍功能叠加层显示基于 ARIA 创作指南的警告和建议。

它看起来像这样

它并不完美，但它应该为您提供一些关于您可以在哪里改进无障碍功能的快速见解。

总结

GTK 4.12 将具有更好的开箱即用无障碍功能以及可帮助您使应用程序无障碍的新工具。

尽情享受吧！❤️

这是新开发周期的第一个 GTK 快照。最近有很多事情都到位了，所以值得花一些时间来详细了解一下新内容，以及您可以在 4.12 中看到的内容。

列表视图改进

GtkListView、GtkColumnView 和 GtkGridView 小部件系列是 GTK 4 中的一个重要补充。它们旨在取代 GtkTreeView，但到目前为止，这显然仍然有点理想化。

在 GTK 4.10 中，我们终于迈出了重要一步，将 GtkFileChooser 从树视图移植过来——这表明列表视图已准备好投入使用。下一个 GTK 4 版本将带来一些缺失的功能

• 最后，修复了长期存在的滚动错误
• 更好的键盘导航，具有可自定义的选项卡行为
• 焦点控制
• 程序化滚动
• 可能的分段

其中一些已在 4.11.1 中提供。我们甚至设法将滚动修复程序反向移植到 4.10.1。

更好的纹理

纹理在 GTK 的 GL 渲染器中经常使用 - 用于图标和图像、字形以及中间的屏幕外渲染。大多数时候，我们不必考虑它们，它们就能正常工作。但是，如果纹理是应用程序的主要内容，例如在图像查看器中，则您需要对其进行更多控制，并且重要的是，边缘情况可以正常工作。

在 GTK 4.10 中，我们引入了一个 GskTextureScale 节点，该节点允许应用程序控制在向上或向下缩放纹理时应用的滤镜。这使应用程序可以使用 GSK_SCALING_FILTER_TRILINEAR 请求使用 mipmap。当有利时，GTK 4.12 将自动使用 mipmap。

我们最近探索的一个边缘情况是纹理切片。只要纹理大于 GL 堆栈支持的大小，GSK 就会将其分解为较小的切片，并为每个切片使用单独的 GL 纹理。现代 GPU 支持巨大的纹理（在我的系统上，最大纹理大小为 16384），这意味着切片支持在实践中很少进行测试，并且我们的单元测试也没有很好地覆盖它。

我们添加了人工限制纹理大小的支持（使用 GSK_MAX_TEXTURE_SIZE 环境变量），并立即发现我们的纹理切片支持需要一些改进。它在 4.12 中会运行得更好。

分数缩放

它在 4 月 1 日发布，但这不是一个玩笑。

我们已向 Wayland 后端添加了对实验性 wp_fractional_scale_manager_v1 协议的支持，并使用 wp_viewporter 协议来告知合成器有关缓冲区正在使用的缩放比例。很高兴它很容易适应我们的渲染堆栈，但是不要期望奇迹。它在 cairo 渲染器上运行良好（如您在视频中看到的），但是我们仍然认为它在 GL 和 Vulkan 渲染器中是实验性的。

要使用 GL 渲染器尝试分数缩放，请设置

GDK_DEBUG=gl-fractional

在环境中。

总结

GTK 4.11 中有很多新事物可以探索。请尝试它们，并在 gitlab 或 Discourse 上告知我们您的想法。

一些核心的 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 基金会支持我们的会议。❤️

在上一篇文章中，我们讨论了弃用树状视图和单元格渲染器等内容。所有这些弃用都会给使用这些 API 的应用程序和库带来大量工作，那么我们为什么要这样做呢？

原因之一是为了启用新功能。例如文件选择器的网格视图。我们花了 18 年才实现！您可以在 Bugzilla 中查看原始功能请求。由于 GtkListView 和 GtkGridView 可以使用相同的数据模型，因此现在很容易实现。

这是文件选择器，带有一个新的视图切换

这是网格视图本身
从合并请求上的点赞数量来看，这是一个很受欢迎的功能。我们希望你喜欢它。❤️

如果您想支持这项工作，请考虑向支持 GTK 开发的 GNOME 基金会捐款。您可以点击这里进行捐款。

如果您正在关注 GTK 的 git 存储库，您可能已经注意到最近几周的变化。

我们有一个目录gtk/deprecations，该目录旨在包含实现已弃用 API 的源文件，这些文件将在下一个主要版本中删除。对于 4.0 版本，我们清空了它，并且从那时起它一直是空的。但最近，它又开始积累文件。

这是一个很好的机会，提醒大家我们如何在 GTK 中使用弃用。但首先，让我们看一下细节。

细节，第 1 部分：单元格渲染器

在 GTK 4 中，我们引入了一个新的基于列表模型的列表和网格窗口小部件系列：GtkListView、GtkColumnView、GtkGridView。还有一个使用列表模型的新组合框实现，称为 GtkDropDown。总而言之，这些旨在为你在 GTK 3 中使用单元格渲染器可以完成的所有操作提供替代方案。

最终目标是删除单元格渲染器，因为它们是一个独立的渲染和布局系统，它往往会干扰 GTK 的 CSS 和布局机制，并使一切变得更加复杂。

但我们并没有完全在 4.0 中完成，主要是因为我们在 GTK 本身中仍然大量使用树状视图。首先也是最重要的，是文件选择器。由于文件选择器将在 4.10 中被移植为使用 GtkColumnView，现在是弃用单元格渲染器机制和所有使用它们的窗口小部件的正确时机。

这是一大段代码，超过 75000 行。

细节，第 2 部分：对话框

在 GTK 4 中，我们删除了 gtk_main() 和 gtk_dialog_run()，因为最好避免递归主循环。同样，我们没有完成，也无法删除 GtkDialog 本身，因为它被用作我们所有复杂对话框的基类。

GTK 4.10 为我们的“选择器”对话框引入了替代 API。新 API 遵循 gio 异步模式。这是一个例子

GtkFileDialog * gtk_file_dialog_new (void);

void            gtk_file_dialog_open (GtkFileDialog *self,
                                      GtkWindow *parent,
                                      GFile *current_file,
                                      GCancellable *cancellable,
                                      GAsyncReadyCallback callback,
                                      gpointer user_data);

GFile *        gtk_file_dialog_open_finish (GtkFileDialog *self,
                                            GAsyncResult *result,
                                            GError **error);

这在 C 中可能看起来有点笨拙，但它可以很好地转换为具有承诺和异常概念的语言

try {
  const file = await dialog.open(parent, ...);
  
  ...
} catch (e) {
  ...
};

要了解有关新 API 的更多信息，您可以查看它们的在线文档：GtkColorDialog、GtkFontDialog、GtkFileDialog、GtkAlertDialog。

有了这些替代方案，我们可以弃用选择器接口、它们的窗口小部件实现以及它们的基类 GtkDialog。

无需惊慌

GTK 中的弃用是针对下一个主要版本中将出现的中断 API 兼容性的更改的早期展望。但是最终的 GTK 5 发布仍然遥遥无期。我们甚至还没有为它制定计划。

绝对没有必要急于进行“弃用清理”。只有在您想要移植到 GTK 5 时才需要删除所有对弃用的使用 - 而 GTK 5 尚不存在。

不过，您仍然可以做一些事情。我们在 4.10 中引入弃用是为了让我们的用户有时间适应，并对我们的想法提供反馈。如果您想这样做，您可以在gitlab中提交问题，在discourse中开始讨论，或者在matrix上找到我们。

与此同时...

弃用警告可能很烦人，但幸运的是，有简单的方法可以关闭它们。对于偶尔调用已弃用函数的情况，最好将其包装在 G_GNUC_BEGIN/END_IGNORE_DEPRECATIONS 中

G_GNUC_BEGIN_IGNORE_DEPRECATIONS
gtk_dialog_add_button (dialog, "Apply", GTK_RESPONSE_APPLY);
G_GNUC_END_IGNORE_DEPRECATIONS

如果您确定您永远不想看到任何弃用警告，您也可以只将 -Wno-deprecated-declarations 传递给 gcc。

我之前写过关于 GTK 中字体处理的文章 之前。这篇文章将重点介绍如何在您的应用程序中使用更高级的字体（和字体选择器）功能。

查找字体

文件选择器最突出的最终用户功能当然是您可以使用搜索条目按名称搜索字体

一个更隐蔽的功能是，你可以根据各种标准过滤列表。其中一个标准是仅显示等宽字体，另一个标准是仅显示覆盖特定语言的字体。

这里需要注意的一个小细节是，GTK会自动更改预览文本以匹配你正在筛选的语言。

少即是多

字体选择器返回一个 PangoFontDescription，其中包含所选字体的完整详细信息：字体系列、样式、大小等。如果你的应用程序只需要字体系列，那么让用户选择样式和大小，最终却被忽略，这会让人感到困惑。

如果你的应用程序是这种情况，你可以使用 gtk_font_chooser_set_level() 和 GtkFontChooserLevel 标志来指示 GTK 你需要的字体详细信息。

typedef enum {
  GTK_FONT_CHOOSER_LEVEL_FAMILY     = 0,
  GTK_FONT_CHOOSER_LEVEL_STYLE      = 1 << 0, 
  GTK_FONT_CHOOSER_LEVEL_SIZE       = 1 << 1,
  GTK_FONT_CHOOSER_LEVEL_VARIATIONS = 1 << 2,
  GTK_FONT_CHOOSER_LEVEL_FEATURES   = 1 << 3
} GtkFontChooserLevel;

例如，在

gtk_font_chooser_set_level (chooser, 
                            GTK_FONT_CHOOSER_LEVEL_FAMILY);

之后，字体选择器看起来像这样

简洁多了！

深入深渊

现代字体是复杂的野兽，表面之下隐藏着许多东西。如果你告诉 GTK 字体选择器，它可以使许多字体功能可用。

首先，有字体变体。这些让你（只要这些特征作为变体轴暴露出来）可以连续地改变字体的特征。

 

典型的变体轴是字体的粗细、宽度和倾斜度，但也可以有其他的（例如本例中的光学尺寸）。

选定的变体是字体选择器返回的 PangoFontDescription 的一部分，应用程序无需进行任何额外的工作即可应用它们。只需像往常一样使用字体描述即可。

要在 GTK 文件选择器中启用字体变体支持，请使用 GTK_FONT_CHOOSER_LEVEL_VARIATIONS 标志

level = level | GTK_FONT_CHOOSER_LEVEL_VARIATIONS;
gtk_font_chooser_set_level (chooser, level);

更多功能

字体不仅包含字形轮廓，还包含许多其他数据，可以在渲染这些字形时以各种方式应用。这包括传统的字距调整和连字等数据，还包括可选的字形形状或定位变体，甚至颜色调色板。在 OpenType 功能 的帮助下，用户可以启用其中的许多功能。

这是一个关于字形形状变体的 OpenType 功能的示例

从左到右切换时在此处切换的功能称为 ss12。值得庆幸的是，该字体还提供了更具意义的名称“Single-story g”。

此示例显示了 frac 功能对分数显示的影响。

在 GTK 字体选择器中，OpenType 功能与变体显示在同一页面上。正如你所看到的，它们可能有很多

请注意，Pango 将 OpenType 功能视为与字体本身分离。它们不是字体描述的一部分，但必须通过 PangoAttributes 或通过 Pango markup 应用于文本。

要应用来自 GTK 字体选择器的选定字体功能，请调用 gtk_font_chooser_get_font_features () 并将返回的字符串传递给 pango_attr_font_features_new()。

要在 GTK 文件选择器中启用 OpenType 功能支持，请使用 GTK_FONT_CHOOSER_LEVEL_FEATURES 标志

level = level | GTK_FONT_CHOOSER_LEVEL_FEATURES;
gtk_font_chooser_set_level (chooser, level);

总结

总而言之，你可以使用 GtkFontChooser 的 level 属性来影响你为应用程序用户提供的字体选择粒度。如果包含字体功能，请不要忘记使用 PangoAttributes 或 markup 应用选定的功能。

所有这些都由 harfbuzz 提供，它为我们提供了一个跨平台的字体及其所有功能的 API。否则是不可能实现的。值得指出的是，这是通过直接访问 harfbuzz 对象来完成的，而不是将所有 harfbuzz API 包装在 Pango 中。

 

 

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 键码（例如用于组合标记）可以正常工作。

表情符号

我们的 Emoji 数据已更新至 CLDR 39，并且我们正在寻找按语言和地区（例如 it-ch）翻译的 Emoji 数据。

调试

检查器现在默认启用，因此调试 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%

您可能已经注意到，最近 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 离线使用，Devhelp 41 将于明年 9 月与 GNOME 41 一起发布。

在线文档

GTK 参考的规范在线位置现在是 docs.gtk.org。您将在那里找到以下 API 参考：

• GTK、GDK 和 GSK
• Pango
• GdkPixbuf
• GLib、GObject 和 GIO

GTK3 和 ATK 的 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 中的文本编辑。

简单：快捷方式

也许您只需要将一些键作为编辑命令来处理，例如 Ctrl-z 用于撤消。在这种情况下，您只需使用带有操作的快捷方式，并在小部件 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 一样。

可以在此处找到用于单字符输入的完整示例。