Subject: Re: FVWM: PipeRead and mouse grab

From: John Latham <[email-masked]>
Date: Wed, 21 Aug 2002 16:25:35 +0100

> From: Dominik Vogt <[email-masked]>
> 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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Dan Espen <[email-masked]>
Date: Wed, 21 Aug 2002 11:40:40 -0400

...
> multiple ones in an example: e.g. the Capture Window example would be an

The rlogin form shown in the man page has multiple commands
attached to one button.  I guess the man page could be more specific
though.  I'll fix it in a minute.

-- 
Dan Espen                           E-mail: [email-masked]
444 Hoes Lane  Room RRC 1C-214      Phone: (732) 699-5570
Piscataway, NJ 08854
--
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-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 21 Aug 2002 18:39:00 +0200

> as the following Prev (Capture) Iconify would be executed during the Exec of

Right.  executing it directly with "> /dev/null" is the most
reliable approach.

> description would be useful, if you don't mind me saying so.

I will write some warning to discourage the potential user of
relying on such undocumented 'features'.

> bits of output from the program being read into the pipe.

You're right.

> But the PipeRead

I wonder if any effort should be made to ease using functionality
that does not work well.  Maybe it should rather stay unintuitive
so that users have to ask on the list before doing such things.

> at the end grab the mouse (waiting if necessary) and restore focus?

Doesn't work with functions that set the focus explicitly.  There
are numerous occurances where you want the focus change.

> PipeRead

Maybe not for core dumps, but our users will tear down the whole
place :-)

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [email-masked], 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-masked].
To report problems, send mail to [email-masked].