On Wed, Jul 30, 2003 at 11:52:57AM +0200, Dominik Vogt wrote: > On Wed, Jul 30, 2003 at 10:08:32AM +0200, Olivier Chapuis wrote: > > On Tue, Jul 29, 2003 at 10:35:49AM +0200, Dominik Vogt wrote: > > > On Mon, Jul 28, 2003 at 07:37:17PM +0200, Olivier Chapuis wrote: > > > > In fact I can reproduce the gkrellm problem only on certain condition: > > > > I've a FvwmEvent running which executes a complex function on each > > > > module events. fvwm bell and abort a complex function which is run > > > > with a raise_window (gkrellm) or a configure_window (Mozilla resizing > > > > with grip). Also I've an FvwmEvent which auto shade a FvwmButtons with > > > > a delay via leave_window (with the schedule command and a "shade" > > > > complex function). When, I leave the FvwmButtons and popup a menu of > > > > an application before auto shade the "auto shade" complex function > > > > xbell and abort. > > > > > > > > So I really think that by default we should not abort complex > > > > functions when we cannot grab the cursor. Maybe a Grab prefix or a > > > > Grab function (with automatic ungrab) should be introduced, but I > > > > _think_ that the case where we need to grab is exceptional. Do you > > > > have a real life example (say in your fvwm config)? > > > > > > The pointer *must* be grabbed during function execution. We have > > > made various attempts to ignore this in the past, and they all > > > ended in disaster. For example, if the user can click in windows > > > (or release a button - quite likely during function execution) she > > > can cause EnterNotify and LeaveNotify events, screwing up scripts > > > that make tricky use of Raise/Lower/Focus. > > > > > > > But it seems to me that we need grabing only if the function has > > a non immediate context? > > No, that is wrong. > > AddToFunc foo > + I do this > + I do that > Mouse 1 t n foo > > is no better than > > AddToFunc bar > + C do this > + C do that > Mouse 1 t n bar >
The situation is differrent. With the "I" function "do this" and "do that" are a priorie executed immediatly (but see below). With the "C" function "do this" and "do that" are executed after button release only. > For example, look at this: > > Style * SLoppyFocus > AddToFunc next_focus > + I next focus > + I next warptowindow 0 0 > mouse 1 t n next_focus > > If the pointer is not grabbed, the following may happen: > > 1) User presses mouse button on window title (triggering > EnterNotify/LeaveNotify events). > 2a) Some application grabs the pointer. This may cause > EnterNotify/LeaveNotify events. > 2b) Fvwm focuses next xterm and warps the pointer into the > window, generating more EnterNotify/LeaveNotify events. > 2c) User releases button (more EN/LN events). > > Which window ends up with the focus is more or less random. It > depends on the order of 2a, 2b and 2c and possibly the windows > involved. > Unable to reproduce this, but this is not the point (do not found a method to get 2a). At first I thought that 2a) cannot cause problem as 2b should be executed "immediately". At least I thought fvwm does not process events between 1 and 2b (and I think that fvwm should not). But I've noted that the trigger_evtype of execute_complex_function is lost sometime (using Next is an example) so DeferExecution forces focus to be executed only when the button is released. It seems to me that this is a bug. In fact it seems that your example can happen on exceptional situation because DeferExecution run over focus will try to grab and if it fails will abort focus. Of course I think that it is a bug that we DeferExec at this point (but it is one reason for precessing event). I may miss something (function code is complex), but this is not my point too. > This is not theory - the grabs are there for exactly this reason. and also for a correct (and fast) detection of M, D, H conditions. > There is no reliable way of filtering out the random events caused > by applications. > > > It is simple to detect this situation and > > to non grab (or grab fast, i.e., try to grab only once and do > > not abort if grabbing fail) for "immediate only" function. I've > > writting such a patch and cannot reproduce problem. > > > > What do you think? > > I think it will replace one kind of problems with another one. > Yes maybe, but I really would like to found a solution (Note the examples with FvwmEvent). I recall the current way of executing complex function regarding these problems: Grab and really try to grab (this may take a few seconds) and if the grab fail abort the func (and essentially this is in this case that the grab procedure take a _few seconds_). fvwm grabbing is slow because basically fvwm wait for success. An alternative interesting method: Try to grab fast (just try to grab once or twice) and _if the grab fail_ execute the func anyway. (an obvious alternative is to try to grab fast and if the grab fail abort the function, but see below). The first remark is that in most cases the grab will not fail. Moreover, I think that this method should be applied only for totally immediate func (we should really grab for H,M and D). Maybe others conditions can be added. I think it will be difficult to reproduce a problem with this method. Note that we try to grab here. Here a "problem" which can happen with this method (but which has more or less nothing to do with complex function). Type in an FvwmConsole AddToFunc WS + I WindowShade Schedule 5000 All (FvwmConsole) WS then use an app for grabbing the cursor before the scheduled cmd is executed (e.g., by opening a menu of this app and do not close it). When WS is executed, with the current method WS is aborted (after a few seconds of fvwm freeze). With the fast grab and exec method when WS is executed X and fvwm take a lot of CPU (fortunately, at low price) until the app ungrab the pointer (e.g., by poping down the menu) and then the FvwmConsole is shaded (ok). This has nothing to do with complex function as this can be reproduced with the current code with: Schedule 5000 All (FvwmConsole) WindowShade I do not know if this is a real issue but I am just afraid that we should add new prefix commands as ForceGrab (try to grab and do not execute if grabbing fail) and ForceFastGrab (try to grab fast and do not execute if grabbing fail). What do you think of all that? I am ready to work/think on any others proposal suggestion ... Regards, Olivier -- 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]
