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 majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Thu Jul 31 2003 - 04:52:22 BST