> OK, I just tried it with an empty config too, and came across something new > that I'd never noticed before, which may be a clue: The problem seems to be > related to whether or not the "hide xv windows" checkbox is selected before I had not selected that previously. This seems to be key.
> doing the grab. When it is not selected, the problem did not occur. When it > is selected, it occurred every time. I get that to. > > Here's the recipe I followed 4-5 times in a row in bare fvwm, talking to > FvwmConsole manually, to get it to happen: > > 1. start xv > 2. In xv, do a grab (^G) and click the "hide xv windows" checkbox. > 3. Do the screengrab using button 1 (window) or button 2 (swept region) > 4. Iconify # Goes to position A > 5. Move # Manually move icon to position B > 6. Iconify # De-iconify > 7. Do another grab exactly as done in step 2 > 8. Iconify # Goes to position A This recipe does, indeed, recreate the problem. When that box is checked, it iconifies to the default position instead of where it was last iconified. The window is unmapped. I've never programmed this sort of thing, maybe someone else can step forward and describe what the correct behavior is here, but in xvgrab.c, line 64, it invokes XUnmapWindow, where I imagine it should instead be using XIconifyWindow? Maybe FVWM considers unmapped windows to be forgettable? I don't know how to get the current display number, otherwise I imagine you could just replace this unmap with a call to iconify it... (Note: source from here: ftp://ftp.mowgli.ch/pub/debian/pool/unofficial/x/xv/xv_3.10a.orig.tar.gz) > Maybe the act of "hiding the xv windows" also somehow whispers in fvwm's ear > to discard the prior icon position? Just guessing out loud... I'm not qualified to even guess. Maybe an fvwm dev can chime in, as I'm over my head.
