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
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.
This is not theory - the grabs are there for exactly this reason.
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.
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 Wed Jul 30 2003 - 04:53:21 BST