On Tue, Aug 20, 2002 at 05:08:24PM +0100, John Latham wrote: > > From: Dominik Vogt <[email protected]> > > Date: Tue, 20 Aug 2002 17:03:23 +0200 > > .... stuff about BusyCursor and PipeRead with the capture form. > > > > > I have tried this but it does not work. :-( I had not switched on > > > BusyCursor > > > for read anyway -- off by default -- so no surprise. > > > No, it's on by default. > > Hmm - I believed the man page: > > ``The default is: > > BusyCursor DynamicMenu False, \ > ModuleSynchronous False, Read False, \ > Recapture True, Wait False'' > > (I am using FVWM 2.5.2).
Oh, this is so embarassing. You are right, I set this im my config explicitly. Probably some relic of testing. > > Make it a > > single command and it works: > > > > PipeRead "echo 'BusyCursor read off'; echo 'Current (Capture) Iconify'; > > echo xwd -out out.xwd; echo 'Prev (Capture) Iconify'; echo 'BusyCursor read > > on'" > > Slight error in your suggestion echo xwd should be xwd. Actually, I meant "echo exec xwd ...", but your version works as well (as long as xwd doesn't print anything to stdout). > I have just tried it, and it works -- brilliant thanks! > > So, given that I'm convinced that BusyCursor read is already off (sorry!), I > have just tried: > > *CaptureCommand PipeRead "echo 'Current (Capture) Iconify'; xwd -out > /home/jtl/captured-window; echo 'Prev (Capture) Iconify'" > > (i.e. what you suggested, but without the BusyCursor parts, and I need to fix > up the file name part) and... > > IT WORKS!!! > > Maybe it is not so connected to BusyCursor as we thought? Right. > Ah ha -- your next email explains it all. > > > In complex functions, the pointer must be grabbed to prevent > > screwing up certain kinds of functions. > > I now realise this accounts for the problem I had with Wait too, as that was > being executed in a Function (of course). > > I have just looked, but could not find a mention of this in the man page. I > think it is quite a significant feature of functions and ought to be > documented, if you don't mind me saying so. It is not documented because nobody knows exactly what is going on. > Also, is it worth considering having the ability to disable the > grab when the user needs it and knows it is safe to? (When would > it be safe?). The problem is: nobody knows exactly when it is safe. Not even me. All I know is that releasing the grab has the potential to transfer the focus to a random window on the desktop (with MouseFocus or SloppyFocus). Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- Visit the official FVWM web page at <URL: http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
