GTK 开发博客

自 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。