i’m having a serious problem trying to take a snapshot of a window not on the current viewport. windows offscreen, as it were, end up being just black boxes the exact size of the window. i’ve tried using imlib2 (http://fvwm.lair.be/viewtopic.php?t=190) as well as xwd:
$ xwd -silent -id 0xe0000e
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 73 (X_GetImage)
Serial number of failed request: 302
Current serial number in output stream: 302
where 0xe0000e was a window id obtained via xwininfo and was off the current viewport. nothing seems to work… le sigh i’ve poured over the man page but have no likely suspects. please help?
This is exactly as I would have expected – there is no way (in Xlib, let alone FVWM) for a window to be captured/acted upon that isn’t on the current page. To explain why would take a long time. But if you really want to know, I can try.
There are rumors that tell that you can ask a window to draw itself on a buffer, even if it is not visible. Could you deny it, and when you have time, I’d like to have the explanation.
OK, well I can’t deny that there is a “buffer” – what you’re probably describing is the Xserver’s “BackingStore” functionality. This is extremely buggy, and has caused some issues with FVWM in the past, so it’s best not to use it. Most Xservers’ do not, by default.
As to why you can’t access a window (that is, take a picture of it when it is not on the same desk/page as the current viewport) is because windows that are not on the current page are unmapped. This is true when one changes pages/desks – the windows are unmapped, and the windows on the current viewport are remapped. AFAIK, FVWM is the only WM to adopt this technique. What this does mean then, for those windows that are unmapped, that there’s no “easy” way of taking thumbnails of them.
The other approach (and one that was used in VTWM and CTWM) is to use virtual root-windows. This would get around the problem, but this too has its own disadvantages. In the end, I believe the (un)mapping approach FVWM uses, is the best compromise.
