Subject: Re: FVWM: Where is focus during PipeRead from FvwmButtons?

From: John Latham <[email-masked]>
Date: Tue, 20 Aug 2002 15:47:23 +0100

> From: Dominik Vogt <[email-masked]>
> Date: Tue, 13 Aug 2002 01:04:11 +0200

> On Mon, Aug 12, 2002 at 06:36:13PM +0100, John Latham wrote:
> > I use PipeRead a lot as a `synchronised' Exec. I get the impression its
> > behaviour has changed fundamentally since 2.2, in what happens to everything
> > else during a PipeRead. I wonder if this is related to the change of behaviour
> > of the Wait command?
> > 
> > Say I press a FvwmButton button which pops up a menu, I select an item which
> > invokes a function including a PipeRead in it. While this PipeRead is running,
> > I click on another FvwmButton button.
> > 
> > In 2.2, after a delay, the menu associated with the second button pops up.
> > 
> > In 2.4.8, after a delay, the *root* menu pops up!
> > 
> > In 2.5.2 the press of the second FvwmButton button is ignored.
> > 
> > Personally, I prefer the 2.2 behaviour, but the 2.5 one is acceptable. What
> > 2.4 does is quite frightening -- I have accidentally started all sorts of
> > options from the root menu!
> > 
> > I assume the 2.4.8 behaviour is a bug caused by some change since 2.2. Is the
> > 2.5 behaviour deliberate (e.g. to plug the 2.4 bug)? Is the 2.2 behaviour
> > considered bad, or deliberately dumped on the altar of some better gain, or
> > just unintentionally lost?
>
> It's not a bug, it's the watch cursor.  Again, disable it with
>
>   BusyCursor Read off
>
> before your PipeRead calls.  I'm sorry that it gives you so much
> trouble.  The change in cursor shape was intended to give better
> feedback that fvwm isn't accepting input at the moment.  We had
> hoped that the watch cursor would be self explaining.

I had to think about this one -- but now I see what you're saying. If
BusyCursor Read is on, then FVWM keeps the mouse, so any mouse clicks during a
PipeRead over FvwmButtons windows are actually received by FVWM. In 2.4, FVWM
then acts on this queued event after the PipeRead, e.g. popping up the root
menu. In 2.5, FVWM is clever enough to ignore the event if the click was over
a window rather than some uncovered root window space -- very sensible.

I believe that FVWM 2.4/2.5 grabs the mouse even if BusyCursor Read is off
(see previous email), as the behaviour I have just described happens
regardless. Otherwise, your advice to have BusyCursor Read off would probably
give the same behaviour as FVWM 2.2.

Why does FVWM need to grab the mouse in order to show a busy cursor anyway?
Consider some `long' PipeRead being done. One ought to be able to continue
using, say, an xterm, while FVWM is busy. So a click in the xterm would work
as normal, but when the mouse is moved onto the root window, it would show the
busy cursor, so the user knows that the menu will not work yet, etc.. Or am I
missing something? I guess I must be, otherwise you would not have grabbed the
mouse ever, and would have shown a WAIT (watch) cursor at all times when FVWM
was busy, and you wouldn't need a BusyCursor command! So, what am I missing?

I ask because, assuming the grab when BusyCursor is off problem gets fixed,
I'm tempted to not use BusyCursor, but set the root cursor explicitly (e.g.
via xsetroot) to a watch every time I do a PipeRead, and back again when it is
finished (e.g. by a simple wrapper script or M4 define). Would I be asking for
trouble?

> 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: Dominik Vogt <[email-masked]>
Date: Tue, 20 Aug 2002 17:13:02 +0200

> a window rather than some uncovered root window space -- very sensible.

Well, it probably wasn't even a conscious choice.  The events are
eaten up by the wrong window, so we couldn't trigger window
actions even if we wanted to.

> regardless.

In complex functions, the pointer must be grabbed to prevent
screwing up certain kinds of functions.

> Otherwise, your advice to have BusyCursor Read off would probably

Because you can't change the cursor in specific places without
grabbing the pointer.  It's not nice, but can hardly be prevented.

> missing something?

The whole idea of the busy cursor is to indicate when fvwm does
not accept input.  Unfortunately it sometimes blocks useful
operations by other clients.

> I guess I must be, otherwise you would not have grabbed the

That won't be fixed as it *is* a fix for certain functions.  To
circumvent the problem you have to put everything in a single
command (or perhaps a shell script feeding PipeRead).

> finished (e.g. by a simple wrapper script or M4 define). Would I be asking for

No, that's safe.  It just does not change the cursor everywhere as
the busy cursor does.

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