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:
> > On Mon, Jul 28, 2003 at 04:11:15PM +0200, Dominik Vogt wrote:
> > > On Mon, Jul 28, 2003 at 03:52:15PM +0200, Olivier Chapuis wrote:
> > > > On Wed, Jul 23, 2003 at 02:36:59PM +0200, Dominik Vogt wrote:
> > > > > On Wed, Jul 23, 2003 at 08:07:32AM -0400, Ben Winslow wrote:
> > > > > > Since I could reproduce this, I decided to track it down...
> > > > > >
> > > > > > fvwm is indeed trying to grab the pointer and failing [XBell() at
> > > > > > functions.c:992 in execute_complex_function], however, it's not because
> > > > > > of anything Jules has done...
> > > > > >
> > > > > > In ConfigFvwmDefaults, an EWMHActivateWindowFunc function is
> > > > > > defined--whenever gkrellm is clicked on to be moved (I think GTK2 is
> > > > > > what's actually causing this to happen), EWMHActivateWindowFunc is
> > > > > > called, causing this problem.
> > > > >
> > > > > Which gkrellm version? It doesn't happen with 1.2.10. Anyway,
> > > > > this is a gkrellm bug:
> > > > >
> > > > > An application can not expect that the window manager processes
> > > > > any requests (_NEW_WM_ACTIVE_WINDOW client message in this case)
> > > > > while the server/pointer/keyboard is grabbed. This should be
> > > > > fixed in gkrellm.
> > > >
> > > > Maybe. But it is not always needed to grab the pointer when we execute
> > > > a complex function. So, I suggest that when fvwm fail to grab the
> > > > pointer for executing a complex function we do not abort the function
> > > > execution. This fix Jules problem (that I can reproduce, and it
> > > > happens the same thing with the Mozilla resize grip). What do you
> > > > think?
> > >
> > > I think it's a bad idea. It is practically impossble to guess
> > > whether a function needs to grab the pointer before executing or
> > > not, and it depends on what other application do too. For
> > > example, if an application warps the pointer while a function is
> > > executed, all sorts of strange things can happen.
> > >
> >
> > 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? 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?
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 Wed Jul 30 2003 - 03:04:18 BST