> From: Dominik Vogt <fvwm_at_fvwm.org>
> Date: Tue, 20 Aug 2002 19:25:25 +0200
> On Tue, Aug 20, 2002 at 05:08:24PM +0100, John Latham wrote:
> > .... stuff about BusyCursor and PipeRead with the capture form.
> > > No, it's on by default.
> >
> > Hmm - I believed the man page:
> Oh, this is so embarassing. You are right, I set this im my
> config explicitly. Probably some relic of testing.
No worries - easily done.
>
> > > 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).
Good point about stdout from xwd -- I should redirect it to /dev/null. I did
wonder if you meant "echo exec xwd ...", but thought it would not be reliable,
as the following Prev (Capture) Iconify would be executed during the Exec of
xwd. True?
> > I have just tried it, and it works -- brilliant thanks!
In the end I have gone for multiple *CaptureCommand lines because I couldn't
get the PipeRead version to work well on FVWM2.2 for some reason!! (Which is
not work looking at.)
*CaptureButton continue "Capture" ^M
# Must not use a function for CaptureCommand,
# because of mouse grab during functions.
# This configuration works with FVWM 2.2, 2.4 and 2.5
*CaptureCommand BusyCursor read off
*CaptureCommand Current [Capture] Iconify
*CaptureCommand PipeRead "xwd -out \"$(file)\" $(Options);"
*CaptureCommand Prev [Capture] Iconify
*CaptureCommand BusyCursor read on
>From the FvwmForm man page, it is not explicitly clear that you can have
multiple command lines for one button and that they are executed by FVWM in
the order specified, but it seems to work fine. Is it worth putting some
multiple ones in an example: e.g. the Capture Window example would be an
obvious one? :-)
...
> > > 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.
I can believe it! :-) However, even a one-line mention in the AddToFunc
description would be useful, if you don't mind me saying so.
> > 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).
Yes, I can see that. It is probably never safe to release the mouse. However,
your proposed workaround of using a PipeRead must suffer from the same lack of
safety (if BusyCursor read is off): e.g. if the user moves the mouse between
bits of output from the program being read into the pipe. But the PipeRead
workaround is much less convenient than just having something like a
``UnsafeMouseFocus'' option on AddToFunc. (I am thinking of writing a bit of
M4 to turn a function into a PipeRead just for this workaround!)
Or, at the risk of me showing total ignorance, would it be possible to make
Wait and PipeRead (etc). always release the mouse (or maybe only if BusyCursor
is off) when they start, but first remember the window which is focussed. Then
at the end grab the mouse (waiting if necessary) and restore focus? PipeRead
would also do a grab/restore before it executes each command it receives, and
release again afterwards. Or is that looney and asking for stacks of core
dump?
>
> Bye
>
> Dominik ^_^ ^_^
Best wishes, John Latham
--
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 majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Wed Aug 21 2002 - 10:26:31 BST