On Thu, Jul 31, 2003 at 11:32:05AM +0200, Olivier Chapuis wrote: > 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). Welcome to maintenance hell: - apparingly random results in funtion execution - random fvwm freezes if XQueryPointer or similar funcitons are called while an application holds a grab > 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. Somethimes I feel like talking to a wall. See my previous mails. > 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 ... I'm 100% against it. Not that my opinion counts for much in this place anymore... Bye Dominik ^_^ ^_^ -- 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]
