桌面应用程序之间用户发起的数据传输的传统方法是剪贴板或拖放。GTK+ 从一开始就支持这些方法，但直到 GTK3，我们用于此类数据传输的 API 都是对相应的 X11 API 的简单伪装：选择、属性和原子。这并不奇怪，因为整个 GDK API 都是以 X11 为模型的。不幸的是，该实现包含诸如增量传输和字符串格式转换之类的恐怖之处。

对于 GTK4，我们正在抛弃这些东西，因为我们正在将 GDK 中的内容移动到更接近 Wayland API 的位置。数据传输是这个现代化最迫切的领域之一。值得庆幸的是，它现在几乎已经完成，因此值得看看发生了哪些变化，以及未来会如何运作。

概念

如果您的应用程序要发送的数据不是字符串，它可能是一些对象，例如 GFile、GdkTexture 或 GdkRGBA。接收端的应用程序可能不使用 GTK 或 GLib，因此不会知道这些类型。即使知道，也没有办法将对象从一个进程完整地传递到另一个进程。

核心上，数据传输的工作原理是从源应用程序发送一个文件描述符，目标应用程序从中读取字节流。剪贴板和 DND 的协议使用 mime 类型（如 text/uri-list、image/png 或 application/x-color）来标识字节流的格式。

发送对象涉及协商双方都支持的数据格式，在源端将对象序列化为该格式的字节流，传输数据，并在目标端反序列化对象。

本地情况

在继续讨论具体的 API 之前，值得花一点时间考虑另一种常见的数据传输情况：在单个应用程序内部。使用相同的剪贴板和 DND 机制将数据从应用程序的一侧发送到另一侧是很常见的。由于在这种情况下我们没有跨越进程边界，因此我们可以避免字节流以及相关的序列化和反序列化开销，而只需传递对该对象的引用来传输数据。

API

上一节中我们提到的对象由 GType（如 G_TYPE_FILE 或 GDK_TYPE_TEXTURE）描述，而如前所述，Wayland 和 X11 协议中的数据交换格式由 mime 类型描述。

我们引入的第一个处理这些类型的 API 是 GdkContentFormats 对象。它可以包含一个格式列表，这些格式可以是 GType 或 mime 类型。我们使用 GdkContentFormats 对象来描述应用程序可以提供数据的格式，以及应用程序可以接收数据的格式。

您可能想知道为什么我们将 GType 和 mime 类型混合在同一个对象中。答案是我们希望使用相同的 API 处理跨进程和本地情况。虽然我们需要为跨进程情况匹配 mime 类型，但我们需要 GType 来处理本地情况。

转换

我们仍然需要一种方法来关联 GType 和 mime 类型，以便它们可以相互转换。这由 GdkContentSerializer 和 GdkContentDeserializer API 处理。它们本质上是转换函数的注册表：GdkContentSerializer 知道如何将 GType 转换为 mime 类型，而 GdkContentDeserializer 处理另一个方向。

GDK 具有常用类型的预定义转换，但该系统可以使用 gdk_content_register_serializer 和 gdk_content_register_deserializer 进行扩展。

内容

现在我们知道如何描述格式并在它们之间进行转换，但是为了将它们整合在一起，我们仍然需要一个方便的 API，该 API 在一侧获取对象，并在另一侧提供字节流。为此，我们添加了 GdkContentProvider API。

GdkContentProvider 允许您将对象与输入侧的格式描述组合在一起，并在输出侧提供一个异步写入器 API，该 API 可以连接到我们要通过其发送数据的文件描述符。

典型的 content providers 是这样创建的

gdk_content_provider_new_for_value (gvalue)
gdk_content_provider_new_for_bytes (gbytes, mimetype)

它接受的 GValue 同时包含对象及其类型的信息，因此如果我们以 GBytes 的形式提供对象（本质上只是一小段内存），则不需要额外的类型信息，我们需要单独提供类型信息。

剪贴板

GTK3 有一个 GtkClipboard 对象，它为复制/粘贴操作提供实现。在 GTK 中拥有此对象并不理想，因为它需要在 GTK 支持的平台上具有不同的实现。因此，GTK4 将该对象移动到 GDK，并因此将其重命名为 GdkClipboard。它也已移植到上述新的数据传输 API。要在 GTK4 中将数据放入剪贴板，您可以使用“set”API 之一

gdk_clipboard_set_content()
gdk_clipboard_set_value()
gdk_clipboard_set_text()

最终，所有这些函数都会将 GdkContentProvider 与剪贴板关联起来。

要在 GTK4 中从剪贴板读取数据，您可以使用异步“read”API 之一

gdk_clipboard_read_async()
gdk_clipboard_read_value_async()
gdk_clipboard_read_text_async()

拖放

GTK3 拖放 API 涉及侦听 GtkWidget 上的多个信号，并为拖动源和目标调用一些特殊的设置函数。它很灵活，但通常被认为是令人困惑的，我们在这里不会详细描述它。

在 GTK4 中，拖放 API 已围绕内容提供程序和事件控制器的概念进行了重组。要启动拖放操作，您可以创建一个 GtkDragSource 事件控制器来响应拖动姿势（您还可以通过直接调用 gdk_drag_begin 来启动“一次性”拖放操作），并为其提供要传输的数据的 GdkContentProvider。要接收拖放操作，您可以创建一个 GtkDropTarget 事件控制器，并在它发出 ::drop-done 信号时调用异步读取方法

gdk_drop_read_value_async()
gdk_drop_read_text_async()

自 GTK 最初开始，容器和布局策略一直是其设计的核心。如果您希望窗口小部件根据特定策略布局其子项，则必须实现 GtkContainer 以处理子窗口小部件的添加、删除和迭代，然后必须实现 GtkWidget 中的大小协商虚函数以测量、定位和调整每个子项的大小。

GTK 4 开发周期的一个主要主题是将更多功能委托给辅助对象，而不是将其编码到 GTK 提供的基类中。例如，我们将事件处理从 GtkWidget 描述的信号处理程序移至事件控制器，并将渲染委托给 GtkSnapshot 对象。该方向上的另一步是将布局机制从 GtkWidget 本身分离到一个辅助类型 GtkLayoutManager。

布局管理器

布局管理器是负责测量和调整窗口小部件及其子项大小的对象。每个 GtkWidget 都拥有一个 GtkLayoutManager，并使用它来代替 measure() 和 allocate() 虚函数，这些虚函数即将被删除。更改的要点：不是子类化 GtkWidget 来实现其布局策略，而是子类化 GtkLayoutManager，然后将布局管理器分配给窗口小部件。

就像旧的 GtkWidget 代码一样，您需要重写一个虚函数来测量布局，称为 measure()，它取代了 GTK 3 的 get_preferred_* 系列虚函数

static void
layout_measure (GtkLayoutManager *layout_manager,
                GtkWidget        *widget,
                GtkOrientation    orientation,
                int               for_size,
                int              *minimum,
                int              *natural,
                int              *minimum_baseline,
                int              *natural_baseline)

测量后，您需要将大小分配给布局；这发生在 allocate() 虚函数中，该函数取代了之前 GTK 主要版本的古老的 size_allocate() 虚函数

static void
layout_allocate (GtkLayoutManager *layout_manager,
                 GtkWidget        *widget,
                 int               width,
                 int               height,
                 int               baseline)

在更深奥的一方面，您还可以重写 get_request_mode() 虚函数，该函数允许您声明布局管理器是否请求固定大小，或者其大小之一是否取决于相反的大小，例如高度对宽度或宽度对高度

static GtkSizeRequestMode
layout_get_request_mode (GtkLayoutManager *layout_manager,
                         GtkWidget        *widget)

您可能会注意到，每个虚函数都会传递布局管理器实例，以及使用布局管理器的窗口小部件。

当然，这对 GTK 窗口小部件的工作方式的各个方面都有更大的影响，最明显的是，现在可以将所有布局代码的复杂性限制在自己的对象中，通常不可派生，而窗口小部件可以保持可派生并变得更简单。

这项工作的另一个特点是，如果您想更改容器的布局策略，则可以在运行时更改布局管理器；您还可以拥有每个窗口小部件的布局策略，而无需增加窗口小部件代码的复杂性。

最后，布局管理器允许我们摆脱 GTK 的特殊情况之一，即：容器子属性。

子属性

在 GtkContainer 的内部，存在一个本质上是 GObject 属性相关代码的副本，其唯一的工作是为从 GtkContainer 派生的类型实现“子”属性。这些容器/子属性仅在子项父级化为特定容器类时才存在，并且用于多种原因，但通常用于控制布局选项，如框和类框容器中的打包方向；GtkFixed 中的固定位置；或笔记本选项卡小部件的展开/填充规则。

子属性很难使用，因为它们需要临时的 API，而不是常用的 GObject API，因此需要在 GtkBuilder、gtk-doc 和语言绑定中进行特殊处理。子属性也附加到容器的实际直接子项，因此如果一个部件插入一个子项——例如，像 GtkScrolledWindow 或 GtkListBox 这样做——那么您需要保留对该子项的引用，以便更改应用于您自己的部件的布局。

在 GTK 的主分支中，我们已经删除了大部分子属性——要么通过简单地删除它们（当有实际的部件 API 实现相同的功能时），要么通过创建辅助的 GObject 类型并将子属性移动到这些类型。最终目标是在 GTK 4 发布时删除所有子属性以及 GtkContainer 中的相关 API。对于与布局相关的属性，GtkLayoutManager 提供了自己的 API，以便在将子项添加到使用布局管理器的部件或从该部件中删除子项时，分别自动创建和销毁对象。创建的对象是可自省的，并且在文档或绑定方面不需要特殊处理。

您首先从 GtkLayoutChild 类派生您自己的类型，并像为任何其他 GObject 类型一样添加属性。然后，您重写 GtkLayoutManager 的 create_layout_child() 虚函数

static GtkLayoutChild *
create_layout_child (GtkLayoutManager *manager,
                     GtkWidget *container,
                     GtkWidget *child)
{
  // The simplest implementation
  return g_object_new (your_layout_child_get_type (),
                       "layout-manager", manager,
                       "child-widget", child,
                       "some-property", some_property_initial_state,
                       NULL);
}

之后，只要一个部件仍然是使用布局管理器的容器的子项，您就可以访问您的布局子对象；如果子项从其父项中删除，或者容器更改了布局管理器，则布局子项会自动收集。

新的布局管理器

当然，仅在 GTK 中拥有 GtkLayoutManager 类对我们没有任何好处。GTK 4 为应用程序和部件开发人员引入了各种布局管理器

• GtkBinLayout 实现了 GtkBin 的布局策略，并增加了一个特性，即它支持多个子项堆叠在一起，类似于 GtkOverlay 的工作方式。您可以使用每个部件的对齐和扩展属性来控制它们在分配区域内的位置，并且 GtkBinLayout 将始终请求分配其最大子项所需的尽可能多的空间。
• GtkBoxLayout 是 GtkBox 实现的布局策略的直接移植；GtkBox 本身已被移植为在内部使用 GtkBoxLayout。
• GtkFixedLayout 是 GtkFixed 和 GtkLayout 的固定布局定位策略的移植，并增加了让您定义通用转换而不是每个子项的纯 2D 平移的功能；GtkFixed 已被修改为使用 GtkFixedLayout 并使用 2D 平移——并且 GtkLayout 已被合并到 GtkFixed 中，因为它唯一突出的特点是实现了 GtkScrollable 接口。
• GtkCustomLayout 是一个方便的布局管理器，它采用曾经是 GtkWidget 虚函数重写的函数，并且主要用作在将现有部件移植到布局管理器未来时的桥梁。

我们仍在实现 GtkGridLayout 并使 GtkGrid 在内部使用它，遵循与 GtkBoxLayout 和 GtkBox 相同的模式。GTK 内的其他部件将在后续过程中获得它们自己的布局管理器，但在此期间，它们可以使用 GtkCustomLayout。

最后一步是实现一个基于约束的布局管理器，这将使我们能够创建复杂的、响应式的用户界面，而无需将部件打包到嵌套的层次结构中。基于约束的布局值得单独写一篇博客文章，敬请期待！

最近在 GTK 主分支中完成的较大重构之一是重做条目层次结构。这篇文章总结了发生了哪些变化，以及为什么我们认为事情会变得更好。

GTK 3 中的条目

让我们先看看 GTK 3 中的情况。

GtkEntry 是这里的基础类。它实现了 GtkEditable 接口。GtkSpinButton 是 GtkEntry 的子类。多年来，添加了更多内容。GtkEntry 获得了对条目完成、嵌入图标和显示进度的支持。我们添加了另一个子类 GtkSearchEntry。

这种方法的一些问题立刻显现出来。gtkentry.c 超过 11100 行代码。不仅很难在这个庞大的代码库中添加更多功能，而且很难对其进行子类化——这是创建您自己的条目的唯一方法，因为所有单行文本编辑功能都在 GtkEntry 内部。

GtkEditable 接口非常古老——它在 GTK 2 之前就已经存在了。不幸的是，它作为一个接口并没有真正成功——GtkEntry 是唯一实现，并且它以一种令人困惑的方式在内部使用接口函数。

GTK 4 中的条目

现在让我们看看 GTK 主分支中的情况。

我们做的第一件事是将 GtkEntry 的核心文本编辑功能移动到一个名为 GtkText 的新部件中。这基本上是一个减去所有额外功能（如图标、完成和进度）的条目。

通过向 GtkEditable 接口添加一些更常见的功能（如 width-chars 和 max-width-chars），并使 GtkText 实现它，我们使 GtkEditable 接口更有用。我们还添加了辅助 API，以方便将 GtkEditable 实现委托给另一个对象。

现在，‘复杂’的条目部件（GtkEntry、GtkSpinButton、GtkSearchEntry）都是组合部件，其中包含一个 GtkText 子项，并将其 GtkEditable 实现委托给这个子项。

最后，我们添加了一个新的 GtkPasswordEntry 部件，它接管了 GtkEntry 过去拥有的相应功能，例如显示大写锁定警告

或让用户查看内容。

为什么这样更好？

这种重构的主要目标之一是使在 GTK 之外创建自定义条目部件更容易。

过去，这需要对 GtkEntry 进行子类化，并浏览一个复杂的 vfuncs 迷宫才能进行重写。现在，您只需添加一个 GtkText 部件，将其 GtkEditable 实现委托给它，就可以轻松地获得一个功能正常的条目部件。

并且您可以灵活地在 GtkText 组件周围添加花哨的东西。例如，我们已经在 gtk4-demo 中添加了一个标记条目，现在可以很容易地在 GTK 之外实现。

从 GTK 3 移植时会影响您吗？

在将代码移植到这种新的条目样式时，需要注意一些可能的陷阱。

GtkSearchEntry 和 GtkSpinButton 不再派生自 GtkEntry。如果您看到关于从这些类之一强制转换为 GtkEntry 的运行时警告，您很可能需要切换到使用 GtkEditable API。

GtkEntry 和其他复杂的条目部件不再可聚焦——焦点会转移到包含的 GtkText 上。但是 gtk_widget_grab_focus() 仍然有效，并将焦点移动到正确的位置。您不太可能受到此影响。

大写锁定警告功能已从 GtkEntry 中删除。如果您使用 visibility==FALSE 的 GtkEntry 来显示密码，您应该只切换到 GtkPasswordEntry。

如果您使用 GtkEntry 进行基本的编辑功能，并且不需要任何额外的条目功能，您应该考虑使用 GtkText 代替。

在 GTK4 中，我们一直在尝试为图像数据找到更好的解决方案。在 GTK3 中，我们用于此目的的对象是pixbufs 和 Cairo 曲面。但它们不再适合，所以现在我们有了 GdkTexture 和 GdkPaintable。

GdkTexture

GdkTexture 是 GdkPixbuf 的替代品。为什么它更好？
首先，它简单得多。API 如下所示

int gdk_texture_get_width (GdkTexture *texture);
int gdk_texture_get_height (GdkTexture *texture);

void gdk_texture_download (GdkTexture *texture,
                           guchar     *data,
                           gsize       stride);

因此，它是一个 2D 像素数组，如果需要，您可以下载像素。它也保证是不可变的，因此像素永远不会改变。存在许多构造函数来从文件、资源、数据或 pixbuf 创建纹理。

但是纹理和 pixbuf 之间的最大区别在于它们不暴露它们用来存储像素的内存。事实上，在调用 gdk_texture_download() 之前，该数据甚至不需要存在。
这用于 GL 纹理。GtkGLArea 小部件例如使用此方法来传递数据。GStreamer 也希望以 GL 纹理的形式传递视频。

GdkPaintable

但有时，您拥有的东西比不可变的一堆像素更复杂。例如，您可能有一个动画 GIF 或一个可缩放的 SVG。这就是 GdkPaintable 的用武之地。
抽象地说，GdkPaintable 是一个接口，用于知道如何在任何大小下渲染自身的对象。受CSS 图像的启发，它们可以选择提供 GTK 小部件可用来放置它们的固有尺寸信息。
因此，GdkPaintable 接口的核心是使可绘制对象自行渲染的函数以及提供尺寸信息的 3 个函数

void gdk_paintable_snapshot (GdkPaintable *paintable,
                             GdkSnapshot  *snapshot,
                             double        width,
                             double        height);

int gdk_paintable_get_intrinsic_width (GdkPaintable *paintable);
int gdk_paintable_get_intrinsic_height (GdkPaintable *paintable);
double gdk_paintable_get_intrinsic_aspect_ratio (GdkPaintable *paintable);

除此之外，当可绘制对象的内容或大小发生变化时，它可以发出“invalidate-contents”和“invalidate-size”信号。

为了使这更具体，让我们以可缩放的 SVG 为例：可绘制对象的实现将返回固有尺寸（这些尺寸函数的返回值 0 可以实现这一点），并且无论何时绘制，它都会在给定大小下以像素精确地绘制自身。
或者以动画 GIF 为例：它会将其像素大小作为固有大小提供，并将动画的当前帧缩放到给定大小。并且每当应该显示动画的下一帧时，它都会发出“invalidate-size”信号。
最后但并非最不重要的是，GdkTexture 实现了此接口。

我们目前正在更改所有在 GTK3 中接受 GdkPixbuf 的代码，以现在接受 GdkPaintable。GtkImage 小部件当然已经更改，拖放图标或 GtkAboutDialog 也已更改。存在实验性补丁，允许应用程序向 GTK CSS 引擎提供可绘制对象。

如果您现在将所有这些关于 GStreamer 可能提供由 GL 图像支持的纹理并创建执行动画的可绘制对象，然后可以将其上传到 CSS 的信息放在一起，您可能会看到它的走向……

GTK 对可加载模块的支持可以追溯到最早的时候，这就是为什么 GTK 有大量代码来处理 GTypeModules 和搜索路径等。很久以后，Alex 为 GVfs 重新审视了这个主题，并提出了扩展点和 GIO 模块的概念，它们实现了这些扩展点。这是一个更好的框架，GTK 4 是我们切换到使用它的绝佳机会。

GTK+ 4 中的更改

因此，我最近花了一些时间在 GTK 中的模块支持上。这里的主要变化如下

• 我们不再支持通用可加载模块。此功能的少数剩余用户之一是 libcanberra，我们将考虑直接在 GTK+ 中实现“事件声音”功能，而不是依赖模块来实现。如果您依赖加载 GTK+ 模块，请来与我们讨论实现您正在执行的操作的其他方法。
• 打印后端现在使用名为“gtk-print-backend”的扩展点定义，该扩展点需要 GtkPrintBackend 类型。现有的打印后端已转换为实现此扩展点的 GIO 模块。由于我们从未支持树外的打印后端，因此这不应影响其他任何人。
• 输入法也使用名为“gtk-im-module”的扩展点定义，该扩展点需要 GtkIMContext 类型。我们已经删除了所有非平台 IM 模块，并将平台 IM 模块移入 GTK+ 本身，同时还实现了扩展点。

调整现有的输入法

由于我们仍然支持树外 IM 模块，我想利用本文的剩余部分来简要概述 GTK+ 4 的树外 IM 模块的外观。

将基于传统 GTypeModule 的 IM 模块转换为新的扩展点需要几个步骤。下面的示例代码取自 Broadway 输入法。

使用 G_DEFINE_DYNAMIC_TYPE

我们将从模块加载一个类型，G_DEFINE_DYNAMIC_TYPE 是定义此类类型的正确方法

G_DEFINE_DYNAMIC_TYPE (GtkIMContextBroadway,
                       gtk_im_context_broadway,
                       GTK_TYPE_IM_CONTEXT)

请注意，此宏定义了一个 gtk_im_context_broadway_register_type() 函数，我们将在下一步中使用它。

请注意，动态类型除了更常见的 class_init 之外，还应该具有 class_finalize 函数，该函数可以是微不足道的

static void
gtk_im_context_broadway_class_finalize
               (GtkIMContextBroadwayClass *class)
{
}

实现 GIO 模块 API

为了可以作为 GIOModule 使用，模块必须实现三个函数：g_io_module_load()、g_io_module_unload() 和 g_io_module_query()（严格来说，最后一个是可选的，但我们仍然会在这里实现它）。

void
g_io_module_load (GIOModule *module)
{
  g_type_module_use (G_TYPE_MODULE (module));
  gtk_im_context_broadway_register_type  
                        (G_TYPE_MODULE (module));
  g_io_extension_point_implement
             (GTK_IM_MODULE_EXTENSION_POINT_NAME,
              GTK_TYPE_IM_CONTEXT_BROADWAY,
              "broadway",
              10);
 }

void
g_io_module_unload (GIOModule *module)
{
}

char **
g_io_module_query (void)
{
  char *eps[] = {
    GTK_IM_MODULE_EXTENSION_POINT_NAME,
    NULL
  };
  return g_strdupv (eps);
}

正确安装您的模块

GTK+ 仍然会在 $LIBDIR/gtk-4.0/immodules/ 中查找要加载的输入法，但 GIO 仅查看名称以“lib”开头的共享对象，因此请确保遵循该约定。

调试

就这样！

现在 GTK+ 4 应该加载您的输入法，如果您使用 GTK_DEBUG=modules 运行 GTK+ 4 应用程序，您应该会在调试输出中看到您的模块。