> From: Dominik Vogt <dominik.vogt_at_gmx.de>
> 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 majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Tue Aug 20 2002 - 09:48:46 BST