Subject: Re: FVWM: window resize in 2.5.7

From: Bill Wilson <[email-masked]>
Date: Fri, 1 Aug 2003 14:15:06 -0500

On Mon, 28 Jul 2003 08:49:35 +0200
"Jules Alberts" <[email-masked]> wrote:

> Op 23 Jul 2003 (14:36), schreef Dominik Vogt <[email-masked]>:
> <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.

> 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 <[email-masked]>:
> > > <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.

Bill

--------
Bill Wilson <[email-masked]>
http://gkrellm.net
--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 4 Aug 2003 09:48:04 +0200

> 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.

> 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 ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Tue, 5 Aug 2003 06:45:23 +0200

> 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?

> 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

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 5 Aug 2003 11:37:22 +0200

> too how this GrabFastForce cmd can fix some others natural pbs.

Really, we do not need to begin this discussion all over again.
This is the thread that started it, so it isn't even new in this
context.

Bye

Dominik ^_^  ^_^