在 Linux 信息亭中，为了“在幕后”重置某些应用程序的状态（当屏幕保护程序使屏幕空白时），我使用了一个 BASH 脚本，其中包括控制面板，任务是最大化 Firefox 窗口。
“wmctrl”向窗口管理器（在我的例子中是 XFWM）发送（异步？）消息以首先找到“窗口 id”：
FF_WID=$(wmctrl -l | grep ' - Mozilla Firefox' | cut -d ' ' -f1)
然后将其最大化至全屏：
wmctrl -ir $FF_WID -b add,fullscreen
问题是，当 Firefox 窗口以某种方式“未完全加载”（即：当窗口管理器已经分配了一个窗口 id 时，但是 - 可能是因为它正在完成时），后一个调用会默默失败（即使使用“详细”开关）绘制小部件？ - 它还无法执行所需的操作 - 最大化）。
sleep N解决方法：基本上，如果在最大化命令之前添加任意延迟： ，则执行该操作。
但缺点有两个：不同的机器需要不同的延迟；另外，如果延迟太长，桌面虽然是空的，但会在明显的时刻可见，这对用户来说并不雅观。
由于（太）短的延迟，显然有一个时刻，进程（Firefox）已经生成，但 WM 的“窗口 ID”尚未分配。一个可能的、更好的解决方法是这样的：
while FF_WID=$(wmctrl -l | grep ' - Mozilla Firefox' | cut -d ' ' -f1) ; do
true
done
wmctrl -ir $FF_WID -b add,fullscreen
但遗憾的是，仅有“窗口 ID”是不够的。这可能是因为有待处理的 GTK 事件在某种程度上阻塞了最大化请求。
通过将 Firefox 替换为另一个 GTK 应用程序（例如“xfce4-terminal”），可以观察到相同的行为。
另一种解决方法 - 但仅在 Firefox 方面有效，而我正在寻求通用解决方案 - 可能是在应用程序端启用日志记录，并在加载阶段监视事件，寻求“应用程序就绪”等。为此，我将使用 Firefox 日志记录工具 (NSPR_LOG_MODULES) 进行一些实验
作为另一个部分解决方法，我已经在 kiosk（全屏）模式下尝试了几个 Firefox 附加组件，但我需要（并实现）在 UI 自定义方面略有不同的行为。
不用说，-fullscreen其他地方记录的 Firefox 切换在 Linux 版本中无效。
通过阅读这另一个问题，并且通过进行大量实验，我倾向于排除在使用或不使用开关-i（名称或整数形式）调用时“wmctrl”可能出现的不同行为的任何问题。
在谷歌上搜索了很多关于这个问题的信息，但没有找到通用且“不太脏”的解决方案。
答：问题真的可能是由 GTK 队列耗尽不完整引起的吗？
乙：（如果 A 为真）是否有一种适用于 BASH 脚本的技术，可以强制延迟仅限于上述队列耗尽的点？
- 我知道有多种方法可以与 GTK 引擎交互，例如通过 Python 或 PERL 绑定。
- 还有一个“gtk-server”适合GTK和BASH脚本之间的交互。
- 还有一个 FFI 接口 (ctypes.sh)，它允许作为 BASH 插件工作，从任何 BASH 脚本直接调用共享库（包括 GTK，任何共享库）。
当然，理想的解决方案将是最水平的可能（不仅适用于 Firefox，而且适用于任何 GTK 应用程序），并且需要尽可能少的数量。程序|解释器|版本相关的黑客安装和维护...
非常感谢您（很长很长）的阅读，祝您有美好的一天