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.
> > 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>
> > > > > > And it does, thanks! Another question (also new behaviour since
> > the
> > > > > > upgrade). When I try to move gkrellm (2.1.12) it stays where it
> > is
> > > > > > until I release the mousebutton, then it pops at the position
> > of the
> > > > > > mousecursor. Any ideas? Thanks!
> > > > >
> > > > > Do you mean by clicking on the internal title of the gkrellm
> > > > > window?
> > > >
> > > > Actually it's the hostname of my box inside gkrellm, and gkrellm is
> >
> > > > "NoTitle'd".
> > >
> > > That's what I meant.
> > >
> > > > It does something else that's weird. If I click hostname and keep
> > mouse
> > > > button 1 pressed, after about 1.5 seconds the PC speaker beeps and
> > I
> > > > can move gkrellm normally.
> > >
> > > Gkrellm is probably trying to grap control of the mouse pointer
> > > but some other application has already grabbed it - most likely
> > > fvwm itself. Do you have any mouse bindings on the 'W' indow
> > > context? A la
> > >
> > > mouse 1 w n ...
> > >
> > > If fvwm has grabbed the pointer, that is because you somehow told
> > > it to do so.
>
> 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.
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 Mon Aug 04 2003 - 02:48:30 BST