In Linux kiosks, in order to reset some applications'state "behind the scenes" (while the screensaver blanks the screen), I use a BASH script which among other things calls wmctrl, with the task of maximizing the Firefox window.
"wmctrl" sends (asynchronous?) messages to the window manager (XFWM in my case) to first locate a "window id":
FF_WID=$(wmctrl -l | grep ' - Mozilla Firefox' | cut -d ' ' -f1)
and then to maximize it to full screen:
wmctrl -ir $FF_WID -b add,fullscreen
The problem is that the latter invocation silently fails (even with the "verbose" switch) when the Firefox window is somehow "not fully loaded" (i.e.: when the window manager has already assigned a window id, but - maybe because it is finishing drawing the widgets? - it is not yet able to perform the action required - maximization).
Workaround: Basically, if an arbitrary delay:
sleep N is added before the maximization command, the action is performed.
But the drawbacks are two: different machines need different delays; plus, if the delay is too long, the desktop, although empty, is visible for a noticeable moment, and this is not tasteful to users.
With (too) short delays there is obviously a moment when the process (Firefox) is already spawned but the WM's "window id" is not yet assigned. A possible, finer, workaround would have been this:
while FF_WID=$(wmctrl -l | grep ' - Mozilla Firefox' | cut -d ' ' -f1) ; do true done wmctrl -ir $FF_WID -b add,fullscreen
But sadly, having a "window id" is not enough. This probably because there are GTK events pending somewhat blocking the maximization request.
The same behaviour is observable by replacing Firefox with another GTK app, like "xfce4-terminal".
Another workaround - but valid only in the regards of Firefox, while I'm seeking a general solution - may be to enable logging on the application side, and watching for events during the loading phase, seeking for an "application ready" or the like. In order to do so, I will experiment a little with the Firefox logging facilities (NSPR_LOG_MODULES)
As another partial workaround I have already tried a couple of add-ons for Firefox in kiosk (fullscreen) mode, but I needed (and achieved) slightly different behaviours in terms of UI customization.
Needless to say, the
-fullscreen switch documented elsewhere for Firefox, is not valid in the Linux build.
By having read this other question, and by having consequently experimented a lot, I tend to exclude any issue with possible different behaviours of "wmctrl" when invoked with or without the
-i switch (name or integer form).
Googled a lot about this problem without finding a general and "not-so-dirty" solution.
A: MAY THE ISSUE TRULY BE CAUSED BY THE INCOMPLETE GTK QUEUE EXHAUSTION?
B: (IF A IS TRUE) IS THERE A TECHNIQUE, APPLICABLE FROM A BASH SCRIPT, TO FORCE A DELAY LIMITED ONLY TO THE POINT WHERE THE ABOVE QUEUE IS EXHAUSTED?
- I know there are several ways to interact with the GTK engine, e.g. via Python or PERL bindings.
- There is also a "gtk-server" suitable for interaction between GTK and BASH script.
- There is also a FFI interface (ctypes.sh) which permits, working as a BASH plugin, direct shared library calls (GTK included, any shared lib) from any BASH script.
Of course the ideal solution will be the most horizontal possibile (valid not only for Firefox but for any GTK app), and will require the least possible number of programs|interpreters|version dependent hacks to install and mantain...
Thanks a lot for the (long, long) reading, have a nice, nice day