Subject: FVWM: gkrellm and FVWM v2.5.8

From: Ryan Daly <[email-masked]>
Date: Wed, 05 Nov 2003 23:17:21 -0500

I'm noticing something strange with 2.5.8 and gkrellm (2.1.21).

I click in the top area to move the window and go to move the mouse, but 
the window stays put.  After about 2 or 3 seconds, I hear a beep and the 
window all of a sudden appears under my pointer ready for me to place it 
anywhere.

If I use my hotkey to move it, I don't get the delay.

Is this a bug or maybe a compile option I missed?

--
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: stu <[email-masked]>
Date: Thu, 6 Nov 2003 11:42:40 +0200

On Wed, 05 Nov 2003 23:17:21 -0500
Ryan Daly <[email-masked]> wrote:

> I click in the top area to move the window and go to move the mouse,
> but the window stays put.  After about 2 or 3 seconds, I hear a beep
> and the window all of a sudden appears under my pointer ready for me
> to place it anywhere.

I get the same result - also with 2.5.8 and gkrellm 2.1.21.

-- 
Stuart Logie
Programmer

UNIVERSAL COMPUTER SERVICES (PTY) LTD
A member of South Africa's largest retail software vendor, the UCS Group

Tel : (011) 712 1371   Cell : 082 902 5632
Fax : (011) 339 3421
Internet : http://ucs.co.za

"I am the Unconquerable Spirit."
               -- Poet Unknown
   
Powered by Debian GNU/Linux - testing/unstable

---

From: Kingsly John <[email-masked]>
Date: Thu, 6 Nov 2003 13:10:23 +0530

> window all of a sudden appears under my pointer ready for me to place it 

I've been having this delay for a long time.. (no beep though) am still on
2.5.7.

Kingsly

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 6 Nov 2003 09:33:52 +0100

> Is this a bug or maybe a compile option I missed?

gkrellm and fvwm are competing for a grab on the pointer.  The
beep indicates that fvwm has finally given up.  Make sure you don
not have any mouse bindings like

  Mouse 1 w ... Function ...

in your fvwm config.  And ask the gkrellm people to use the
method defined in the wm-spec aka EWMH spec to move their windows
rather that doing it on their own.  This would avoid the problem
altogether.

Ciao

Dominik ^_^  ^_^

---

From: Ben Winslow <[email-masked]>
Date: Thu, 06 Nov 2003 12:14:18 -0500

On Thu, 2003-11-06 at 03:33, Dominik Vogt wrote:
> in your fvwm config.

n.b. This won't matter--Not only is a complex function needed to
properly move a window by clicking and dragging, but
EWMHActivateWindowFunc is called when you try to start dragging the
gkrellm window.

The only way I know of to get work around all this is to either call
Move in a context that it doesn't have a window (i.e. the cursor changes
and then you click and drag someplace on the gkrellm window), or to have
a move binding that captures the mouse before gkrellm has a chance (e.g.
I have mod3-mouse1 bound to a complex function that immediately runs
move.)  (The latter appears to be one thing the original poster
mentioned as working.)

-- 
Ben Winslow <[email-masked]>

---

From: Ryan Daly <[email-masked]>
Date: Thu, 06 Nov 2003 14:33:29 -0500

> rather that doing it on their own.  This would avoid the problem

I do have a Function bound to Mouse 1.

Strange thing is though...it works fine with FVWM v2.4.17.

Any ideas on why that is?
--

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 7 Nov 2003 10:28:16 +0100

> EWMHActivateWindowFunc is called when you try to start dragging the

That sounds somewhat familiar.  I think you are right.  So the
problem can be circumvented by either destroying the corresponding
fvwm function:

  DestroyFunc EWMHActivateWindowFunc

(which affects all windows, not just gkrellm).  Unfortunately, it
is not yet possible to disable certain features of the EWMH spec
for individual windows.

Ciao

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 7 Nov 2003 10:28:47 +0100

> Any ideas on why that is?

Because 2.4.x does not have EWMH hints support (see Ben's
posting).

Ciao

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 7 Nov 2003 13:10:43 +0000

> is not yet possible to disable certain features of the EWMH spec

Destroying this function would be undesirable for modern applications
asking the window manager to activate (bring to the user attention) their
windows.

A better solution would be to introduce Grab command and add "Grab off"
to EWMHActivateWindowFunc.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 7 Nov 2003 14:36:55 +0100

> to EWMHActivateWindowFunc.

Deja Vu?  No, it wouldn't.

Ciao

Dominik ^_^  ^_^

---

From: Ryan Daly <[email-masked]>
Date: Fri, 07 Nov 2003 09:28:12 -0500

Ahh, OK.  I see.

Well, should we contact the gkrellm people to fix their application? 
Who would be best to do that and who is the proper person to contact? 
Any idea?
--

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 7 Nov 2003 14:45:30 +0000

> Deja Vu?  No, it wouldn't.

I.e. you say fvwm should know better than the user what to do and
disallow some legitimate functionality. I hope you have a better solution
in mind for this kind of problems regarding fvwm functions.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 7 Nov 2003 16:02:49 +0100

> in mind for this kind of problems regarding fvwm functions.

Like it or not, fvwm functions don't work reliably without the
grab.  Furthermore, they can not work reliably *because of the way
X11 is designed*.  Theoretically, one could improve predictability
of whether a particular function needs the grab or not, but
practically the code is so obscure that it it virtually impossible
to do so (partially since it depends on the behaviour of third
party software).

In the specific case the "Focus" command in EWMHActivateWindowFunc
is one of those that requires the grab to prevent a race condition
between the pointer being moved while the focus is changed.  If
the grab is not held in such a context, releasing the mouse button
leads to more or less random windows being focused (experience
from the past, not something I'm making up).

The situation can be improved by using the Schedule command to
trigger EWMHActivateWindowFunc or UrgencyFunc (plus any others?)
as soon as possible if the grab can not be established
immediately.  THe code handling scheduled functions should have
a similar check too and keep the functions due for execution in
the queue until a grab can be established.  However, it would be
necessary to always make the grab in the scheduler code since it's
impossible to predict whether the grab is necessary or not.

Ciao

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 7 Nov 2003 17:15:14 +0100

On Fri, Nov 07, 2003 at 02:45:30PM +0000, Mikhael Goikhman wrote:
> disallow some legitimate functionality.

In this specific case yes.  How can the user know what's right
here if not even the developers have a clue?

> I hope you have a better solution

Ciao

Dominik ^_^  ^_^