On Wed, Aug 04, 2004 at 03:21:53PM -0700, Tommy C. Li wrote: > Hello, > > It's my perception that the mouse-triggered actions behave > inconsistently with what the manual says. > > Specifically, actions don't seem to be triggered until a click is > completed - not on mouse-down - which is what is suggested by the manual. > > Take for example this quote from the fvwm man page: > > "The name must not contain embedded whitespace. No guarantees are made > whether function names with embedded whitespace work or not. This > behavior may also change in the future without further notice. The > letter before the action tells what kind of action triggers the command > which follows it. 'I' stands for "Immediate", and is executed as soon as > the function is invoked. 'M' stands for "Motion", i.e. if the user > starts moving the mouse. 'C' stands for "Click", i.e., if the user > presses and releases the mouse. 'H' stands for "Hold", i.e. if the user > presses a mouse button and holds it down for more than ClickTime > milliseconds. 'D' stands for "Double-click". The action 'I' causes an > action to be performed on the button-press, if the function is invoked > with prior knowledge of which window to act on." > This suggests that "Immediate" commands are executed on mouse-down, > while "Click" type is for press-and-release.
And it is exactly what fvwm does. With AddToFunc immediate I echo immediate mouse 3 r n function immediate the "echo immediate" is executed as soon the button is pressed, and with AddToFunc click C echo click mouse 3 r n function click There are a couple of exception, though: - If an application is started that tries to grab control of the pointer, it will succeed only after the function is completed. - Commands that change the window focus do change the foucs immediately, but the window decorations are redrawn only after the function completes. Fvwm tracks the focused window by the corresponding X event, and events are not handled during function execution. Hence the delay. - To suppress excessive redrawing, changes in window styles are activated only after the function completes and fvwm is idle (i.e. not receiving events or module input). - If a command needs a window to operate on, and no window has been selected yet, you have to release the button first and then click on a window. Note that the function itself only completes when the last mouse button is released. > I've noticed that Immediate commands are only exceuted after release or > I press and move the pointer a bit. This is certainly not "Immediate" - > and there is a definite need for commands to be executed on mousedown. > > In fact, for all mouse-bindings, actions are excuted on > click-and-release instead of mousedown. Key binding actions are executed > on mouse-down. > And also - there is this entry in the FvwmButtons manpage: > > "ActionOnPress > ~~ Usually the action is executed on the button release except for the > Popup action. This option changes this behavior, the action is executed > on the button press. This may be good, for example, with Menu or > SendToModule that generates popups, or when Frame is 0 and the button > would look unresponsive otherwise." Works as advertised for me. > This suggests that popup actions are executed on mousedown. This is not > the case with buttons. They behave like "Immediate" commands - executing > only on mousedown+movement or mousedown+release. > > If I add ActionOnPress, actions behave like "Immediate" commands again - > that is - not immediately! > > Incidentally, popup menus only behave correctly in keybindings and > mousebindings on the Root Desktop. > > Can anyone shed some light on this issue? It's a major annoyance. Is there any chance your mouse or your X server is broken? When fvwm receives a ButtonPress event it acts immediately. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED]
pgp08gzkkjVBK.pgp
Description: PGP signature
