当我最初开始接触图形编程时 - 我通过计算内存地址然后写入相应的值，将像素绘制到屏幕上。时代已经变了。我早期的编程经历包括 gwbasic、STOS、HiSoft Basic (编译型!)、VisualBasic (多个版本)，直到我接触到 C 和 AES (在 Atari ST 上)、Win16 (即 Windows 3.1) 甚至 OS/2 上的 Presentation Manager (在 Warp 时代之前)。

在大学里，我接触到了 Tru64 平台。这意味着 Alpha 架构和一种与我所知的任何系统都不太兼容的 Unix 方言。我尝试过 xlib 和 GTK，但后来我和一些朋友开始构建 KDE (学校提供了 FVWM)。这意味着要构建 Qt 以及许多其他东西。那是一个 64 位技术还很新奇的时代 - 你猜 Tru64 是运行在什么架构上的。

如果仅仅构建项目还不够让我们忙碌的话，我们还必须在一个临时驱动器上进行构建，因为我们的账户空间太有限了。这意味着要尽量缩短构建时间，以避免每天晚上系统管理员在临时区域运行的rm -rf命令。我们还必须将部分二进制文件放在 Web 目录中，并使用符号链接将它们放入分布在我们主目录树中的位置（当他们意识到我们所做的事情时，引发了一些激烈的讨论）。系统管理员吸取的教训是，应该在所有磁盘上运行配额检查 - 而不仅仅是 /home 目录树...

怀旧就到此为止，回到正题。根据我之前的所有经验，图形都是放置在特定的像素位置。通常是相对于左上角（即帧缓冲内存的基地址）或相对于当前父窗口部件的左上角（即窗口内部）。Windows 通过使用对话框单元使情况变得复杂，即基于字体大小来确定位置。

构建 Qt 意味着尝试使用 Qt，这使我超越了固定像素位置的限制。我并不是说 Qt 是第一个做到这一点的，也不是说它是最好的。像所有伟大的想法一样，这肯定是受到了某些启发。在 Qt (以及 GTK+ 和大多数其他现代工具包) 中，窗口部件 (控件、元素，随便你怎么称呼它们) 被放置在“布局”中，这真是太巧妙了。通过让窗口部件提示它们想要的大小，然后提供尺寸策略，布局允许窗口部件协商空间。

让我们举个例子。本文开头所示的非常简单的对话框由三个窗口部件组成：一个文本编辑器 (QLineEdit)、一个按钮 (QPushButton) 和一个列表窗口部件 (QListWidget)。它们都放置在一个网格布局 (QGridLayout) 中，其中列表跨越两列。

所有窗口部件都提供一个尺寸提示，即一些尺寸信息，以便开始协商。尺寸提示通常根据窗口部件的内容计算得出。对尺寸提示的解释可以是：不在意、我更喜欢这个但也可以接受其他尺寸、这是我的绝对最小或最大尺寸，或者这是我的最终尺寸。此外，根据方向（水平或垂直），解释也可能不同。

回到示例对话框，最容易理解的窗口部件是列表。它返回一个小的提示，但希望在任一方向上尽可能地扩展。它对它能得到的空间感到满意，但想要尽可能多的空间。这种尺寸提示解释，或者说尺寸策略，被称为 Expanding（扩展），并在两个方向上都使用。

文本编辑器和按钮都根据内容返回提示。在高度方面，它们都是单行窗口部件（在这种上下文中），因此高度是 Fixed（固定）。眼尖的读者甚至可能会注意到，文本编辑器没有按钮那么高，因此在垂直方向上是居中的。

在水平方向上，按钮提供一个 Minimum（最小）尺寸，以使其文本不会被截断，而文本编辑器则尽可能多地占用空间 (Expanding)。所有这些策略和提示都由网格布局进行平衡，以提供所示的对话框。

那么，布局有什么好处呢？我可以看到三个明显的例子：

1. 国际化 - “Add”在瑞典语中是 “Addera” 或 “Lägg till”。这需要一个更大的按钮 - 这是布局可以处理的，而无需更改对话框。
2. 屏幕分辨率变化 - 即更大的字体（以像素为单位）由布局自动处理，同样无需更改对话框。
3. 可伸缩的用户界面 - 如果列表包含长文件路径，用户只需拉伸对话框即可显示整个路径，对话框控件也会随之伸展。如果没有布局，最终要么需要滚动，要么会错过部分内容。