容器的秘密

我最近花了一些时间追踪 GTK+ 容器和绘图方面的一个问题。以下是我发现的。

CSS 绘图

在 GTK+ 3.22 中,大多数(如果不是全部)容器都支持完整的 CSS 绘图模型,具有多层背景和边框。例如,这就是 GtkFrame 现在绘制其框架的方式。但是,通常只排列其子元素的容器,例如 GtkBox,可以绘制背景和边框。可能性是无限的!

例如,我们可以使用 GtkBox 将边框放在列表框和标签周围,使标签在视觉上看起来像是列表的一部分。您甚至可以使用一些 CSS 使其色彩缤纷且有趣,例如

box.frame {
 border: 5px solid magenta;
}

分配和调整大小

传统上,GTK+ 中的大多数容器都不进行自己的绘制,而只是排列它们的子元素,因此当它们的大小更改时,实际上不需要进行完整的重绘——重绘子元素就足够了。这就是 gtk_container_set_reallocate_redraws() 的作用。在 GTK+ 3 中,它的默认值为 FALSE,因为我们不想在分配发生更改时冒着添加过多重绘的风险。

您可以明白我的意思:如果我使用删除按钮从成分列表中删除黄油和盐,列表的分配(以及它周围的框的分配)将会缩小,并且我们会出现重绘问题。

解决方案

如果您计划让纯布局容器绘制背景或边框,请确保为正确的窗口小部件将 reallocate-redraws 设置为 TRUE(在本例中,是趣味框的窗口小部件)。

gtk_container_reallocate_redraws (GTK_CONTAINER (parent), TRUE);

请注意,gtk_container_reallocate_redraws() 在 GTK+ 3.22 中已弃用,因为我们将在 GTK+ 4 中将其移除并自动执行正确的操作。但这不应阻止您使用它来解决此问题。

另一种(可能更好的)选择是使用旨在绘制边框的容器,例如 GtkFrame。

关于“容器的秘密”的 2 条评论

  1. 嗯,有意思,这是一个即使该函数要被移除,也不应该被弃用的案例,因为您的应用程序没有它就无法正常工作。由于移植到 GTK+ 4 仅仅是删除函数调用,因此在 GTK+ 3 中弃用的价值就低得多。

  2. 我对这个问题的总体看法是,只有当您计划移植到下一个主要版本时,弃用才有用。除非是这种情况,否则您最好忽略它们

评论已关闭。