On Tue, Aug 20, 2002 at 03:47:23PM +0100, John Latham wrote:
> > 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.
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.
> 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.
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
> give the same behaviour as FVWM 2.2.
>
> Why does FVWM need to grab the mouse in order to show a busy cursor anyway?
Because you can't change the cursor in specific places without
grabbing the pointer. It's not nice, but can hardly be prevented.
> 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?
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
> 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,
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).
> 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?
No, that's safe. It just does not change the cursor everywhere as
the busy cursor does.
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 Tue Aug 20 2002 - 10:14:40 BST