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