【发布时间】：2016-04-04 01:20:54
【问题描述】：
我正在编写一个脚本来将内容输出到一个窗口，该窗口包含一个 Tkhtml 小部件和一个在 ttk::panedwindow 中相互叠加显示的文本小部件。这两个小部件都可以垂直和水平滚动。还有一个按钮允许用户清除文本小部件。
我正在运行 Ubuntu 的笔记本电脑上进行一些开发。窗口管理器允许 2x2 阵列中的四个桌面工作区，当第一次显示 GUI 时，底部五分之一左右从我正在使用的工作区流到下面的工作区。不得不四处调整窗口大小以使其足够短以适合屏幕，这很烦人，所以我想调整它的大小。
（我认为）我大致知道如何执行此操作，即绑定到适当的事件，以便我可以在第一次显示窗口时运行脚本。 （从脚本中重置绑定，使其只触发一次。）我相信“适当的事件”是<Map>，但是当第一次映射窗口时，两个小部件的高度为零（如[winfo height] 报告的那样） ）。我尝试绑定到<Expose>，这似乎可行，（[winfo height] 返回合理的数字，）所以：
问题 1：我应该绑定哪个事件？
当绑定触发时，[wm geometry] 将几何报告为 815x1029+49+24，[winfo height] 报告两个小部件的两个高度为 600 和 366，[wm screenheight] 返回高度为 800。我知道那里是 GUI 中的各种其他点点滴滴，所以我对初始布局中有 63 个像素下落不明并不感到惊讶。我假设在调整大小后我需要相同数量的空间，所以我应该请求 815x737+49+24 的几何图形，但是当我这样做时，一条条子（大约是较低的水平滚动条）仍然会渗入下一个工作区。
通过手动处理，我知道当一切都很好地适合屏幕时，几何图形应该是 815x717+49+24，所以我在允许“其他位”的空间量中添加了 20 的软糖因子和 GUI 的碎片”。这工作正常，但似乎有点不雅（大量的英国轻描淡写:-)），所以：
问题 2：我错过了什么，需要使用软糖因素？
我在 Ubuntu 12.04.5 LTS 上使用 Tk 8.6.1。我正在使用 Compiz 窗口管理器的 0.9.7.12 版本。
更新
让我感到震惊的是，我应该找到各种窗格的高度，而不是 Tkhtml 和文本小部件，因为这会解释滚动条和“清除”按钮。窗格高度最初是 615 和 409，但这只是意味着我必须将我的软糖因子从 20 增加到 78 才能使请求高度达到我想要的 717 值。有没有办法预测顶层请求的高度包含我的窗格窗口以使该顶层填满屏幕？
【问题讨论】：
-
winfo height在窗口完全显示之前不会返回合理的数字。您可以使用winfo reqheight在窗口显示之前获取窗口的请求高度。 -
@BradLanam 我原以为
<Map>事件只会在窗口完全显示时触发，但很惊讶[winfo height]那时没有返回合理的数字。<Expose>事件似乎触发得足够晚，以便有合理的数据可以恢复，但我很惊讶我需要使用它，特别是考虑到 Tk documentation 中的这一声明：“客户端应用程序通常不需要处理 Expose 事件，因为 Tk 在内部处理它们”。 -
@BradLanam
[winfo reqheight]没有返回任何有用的信息，因为我没有要求任何特定的高度。 -
reqheight 不绑定到用户请求的高度。它是 tk 的打包算法要求的高度。您将
<Map>绑定到哪个窗口？您可能需要将 -
@BradLanam 我忘记了这种事情有多“有趣”。我确定上次我尝试它时，
[winfo height]在<Map>绑定触发时返回 0。我已经改变了一些事情，以转储窗格窗口和每个窗格、<Map>和<Expose>上的当前和请求的高度（使用[winfo height]和[winfo reqheight]）。两个事件的相同窗口报告相同的值，并且它们始终是合理的（即非零）。以前，我只绑定到窗格窗口。