On Tue, Aug 20, 2002 at 03:47:23PM +0100, John Latham wrote: > > From: Dominik Vogt <[EMAIL PROTECTED]> > > 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: [EMAIL PROTECTED], 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
