Re: FVWM: PipeRead and mouse grab

From: Dominik Vogt <fvwm_at_fvwm.org>
Date: Wed, 21 Aug 2002 18:39:00 +0200

On Wed, Aug 21, 2002 at 04:25:35PM +0100, John Latham wrote:
> > > > 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?

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

> > > > 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.

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

> > > 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.

You're right.

> 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!)

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.

> 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?

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

> 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?

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

Bye

Dominik ^_^ ^_^

 --
Dominik Vogt, mail: dominik.vogt_at_schlund.de, 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 majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Wed Aug 21 2002 - 11:39:45 BST

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:37:53 BST