On Mon, Aug 04, 2003 at 09:48:04AM +0200, Dominik Vogt wrote:
> On Fri, Aug 01, 2003 at 02:15:06PM -0500, Bill Wilson wrote:
> > On Mon, 28 Jul 2003 08:49:35 +0200
> > "Jules Alberts" <jules.alberts_at_arbodienst-limburg.nl> wrote:
> >
> > > Op 23 Jul 2003 (14:36), schreef Dominik Vogt <fvwm_at_fvwm.org>:
> > > <snip>
> > > > Which gkrellm version? It doesn't happen with 1.2.10. Anyway,
> > > > this is a gkrellm bug:
> > >
> > > Over here it's version 2.1.12, I got it from freshrpms.net
> > >
> > > > 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. Could someone report this to the developers?
> >
> > Hi, gkrellm does not do any pointer or keyboard grabs, so I'm really
> > not sure what the issue is here or how it could be a gkrellm bug.
>
> Under X, the pointer is grabbed automatically when a button is
> pressed. Otherwise you could not be sure to ever receive the
> matching button release event (in case the pointer moved into a
> different window). Even if the application does not do anything
> bad itself, it's not a good thing to do to move a window since the
> grab is relatively long lived - with the potential to freeze other
> applications or the window manager.
>
> The best way to handle this is to use the _NET_WM_MOVERESIZE
> client message from the EWMH spec (if it is available). This
> message instructs the window manager to move or resize the window
> itself. The application does not need a pointer grab anymore (or
> can call XAllowEvents to release the existing automatic grab).
> I have no idea how you do this with GTK2.
>
Maybe someone can suggest GTK developper to use _NET_WM_MOVERESIZE
for gdk_window_move?
>
> > > Hello Bill,
> > >
> > > Last week I seem to have found a bug in gkrellm. I found your email
> > > address at the gkrellm site and took the liberty of mailing you this
> > > snip of a thread on the fvwm mailing list.
> > >
> > > I also post this to the mailing list, because if you have technical
> > > questions, I probably won't be able to answer :-)
> >
> > > ----------------------------------------------------------------------
> > > On Wed, 2003-07-23 at 06:31, Dominik Vogt wrote:
> > > > On Wed, Jul 23, 2003 at 11:55:22AM +0200, Jules Alberts wrote:
> > > > > Op 23 Jul 2003 (10:59), schreef Dominik Vogt <fvwm_at_fvwm.org>:
> > > > > <snip>
> > <snip>
> > Gkrellm connects to button press events and when the button is pressed
> > in the hostname area gkrellm then does window moves while it gets
> > mouse motion events (as long as the motion event state indicates the button
> > is still pressed or until it gets a button released event). The moves are
> > done using gdk_window_move() (which calls XMoveWindow()), again without
> > grabbing anything.
>
>
> > > 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.
> >
> > I'm not sure what action GTK2 might be taking, but I've had no reports of
> > any behavior like this with any other window managers.
>
> This is a very window manager specific problem. I guess almost
> all window managers grab the pointer at some time. But it is hard
> to say when this happens. The race condition between gkrellm and
> fvwm is especially bad because it comes from hard wired
> functionality, not random user interaction.
>
When fvwm receives a _NET_ACTIVATE_WINDOW it executes the complex
function EWMHActivateWindowFunc which is defined as:
AddToFunc EWMHActivateWindowFunc
+ I Iconify off
+ I Focus
+ I Raise
we use a complex function for better user control. Now if we had
implemented _NET_ACTIVATE_WINDOW by hardcoding the function, something
like:
if (IS_ICONFIDED(fw))
{
execute_function_override_window(
NULL, NULL, "Iconify off", 0, fw);
}
execute_function_override_window(NULL, NULL, "Focus", 0, fw);
execute_function_override_window(NULL, NULL, "Raise", 0, fw);
then we never had this problem. I suggest various way to fix this
problem ... I recall one: add a "grab fast and execute" dummy cmd for
complex function:
AddToFunc EWMHActivateWindowFunc
+ I GrabFastForce
+ I Iconify off
+ I Focus
+ I Raise
if one of the immediate action of a complex function is GrabFastForce
(we may found a better name) and if the function has only immediate
action we try to grab the pointer only once (this is important) and we
execute the function even if the grab fail.
Again you do not need to have a recent GTK to reproduce the problem
(I've not). You just need to have a FvwmEvent running which executes
a complex function on raise_window (or configure_window). I explain
too how this GrabFastForce cmd can fix some others natural pbs.
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 Tue Aug 05 2003 - 02:06:39 BST