Subject: FVWM: Flickering of buttons and mouse focus

From: Tom Alsberg <[email-masked]>
Date: Sun, 14 Apr 2002 22:23:27 +0300

In the current FVWM (CVS), there seems to be a bug in mouse focus... I
don't really know where the bug really is, but sometimes
windows/widgets act like they lose and get the focus very fast for
some time, like flickering.
In GTK+ applications, for example, sometimes the buttons flicker when
you're over them, and sometimes getting out of the window and getting
back in helps... Also so with Netscape's toolbars sometimes...
Most noticable is in Ghostview for me... When selecting an area with
the middle mouse button, a menu is supposed to show up enabling me to
zoom that area... It always worked, but now the menu appears for a
fraction of a second, and then disappears... That happens only in the
development/alpha FVWM from CVS... With FVWM 2.4.6 it seems fine, as
it does with TWM/CTWM...

Any idea what the problem might be?

  Any help appreciated, thank you,
  -- Tom

-- 
  Tom Alsberg - certified insane, complete illiterate.
        e-mail: <[email-masked]>
	Homepage: http://www.cs.huji.ac.il/~alsbergt/
  * An idea is not responsible for the people who believe in it.
--
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: Mikhael Goikhman <[email-masked]>
Date: Sun, 14 Apr 2002 20:20:15 +0000

> Any idea what the problem might be?

Does this happen with no config file too?
I.e.: fvwm -f no-rc

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 15 Apr 2002 12:42:31 +0200

> Any idea what the problem might be?

I'm aware of this problem but don't know how to reproduce it at
will.  It has been around for a long time though, long before
2.4 was released.  Can you try to find a way to make it happen
fairly reliably?

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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: Tom Alsberg <[email-masked]>
Date: Mon, 15 Apr 2002 19:52:16 +0300

On Sun, Apr 14, 2002 at 08:20:15PM +0000, Mikhael Goikhman wrote:
> > <snip />

No, it doesn't happen without a config file...
I checked a bit further, and found that the problem is related to the
following in my .fvwm2rc - if I remove them then the problem goes
away:

# For auto-raise:
*FvwmEvent:	enter_window	"Silent SelectiveRaise"
*FvwmEvent:	leave_window	"Silent SelectiveLower"

# Functions to auto-raise / auto-lower only some specific windows:
DestroyFunc	SelectiveRaise
AddToFunc	SelectiveRaise
	+ I WindowId $0 (!raised "FvwmIconMan") Raise
	+ I WindowId $0 (!raised "FvwmButtons") Raise
	+ I WindowId $0 (!raised "xclock") Raise
	+ I WindowId $0 (!raised "xexec") Raise

DestroyFunc	SelectiveLower
AddToFunc	SelectiveLower
	+ I WindowId $0 (raised "FvwmIconMan") Lower
	+ I WindowId $0 (raised "FvwmButtons") Lower
	+ I WindowId $0 (raised "xclock") Lower
	+ I WindowId $0 (raised "xexec") Lower

So it apparently happens only with FVWM 2.5 because earlier versions
didn't have the enter_window/leave_window events.

Those lines are for certain windows to be automatically raised and
lowered when the pointer enters and exits them.

I didn't manage to find out the problem in those lines of my
.fvwm2rc... But it might be that I'm missing something... So I'm not
sure if it's a bug or not...

> Mikhael.

  Any help/guidance appreciated, thank you
  -- Tom

---

From: Tom Alsberg <[email-masked]>
Date: Mon, 15 Apr 2002 19:58:21 +0300

> 2.4 was released.  Can you try to find a way to make it happen

Well, it is probably not the same problem then...This problem started
for me with FVWM 2.5... As I wrote in another message in this thread,
it doesn't happen when I remove the following lines from my .fvwm2rc:

# For auto-raise:

The enter_window/leave_window events are new to FVWM 2.5, so that's
it...

I put these lines foir certain windows to be automatically raised and
lowered when the mouse pointer enters and leaves them...

> Dominik ^_^  ^_^

  Any help further appreciated,
  -- Tom

---

From: [email-masked]
Date: Mon, 15 Apr 2002 13:09:29 -0400 (EDT)

>         + I WindowId $0 (raised "xexec") Lower

Why not:

Style "*"		ClickToFocus, SloppyFocus
Stlye "FvwmIconMan"	FocusFollowsMouse
Style "FvwmButtons"	FocusFollowsMouse
Style "xclock"		FocusFollowsMouse
Style "xexec"		FocusFollowsMouse

This should work in all fvwm2 versions from 2.2 onward.

-- 
Larry Gensch                                          [email-masked]

            Working for COMPAQ for over a fourteenth of a century

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 15 Apr 2002 20:51:42 +0000

> This should work in all fvwm2 versions from 2.2 onward.

I am not sure what this should mean, but I suppose this is suggested to
be used together with FvwmAuto, otherwise it just does not do Raise/Lower.

I don't think you may simulate raise on entering special windows and lower
on leaving them using FvwmAuto or FvwmEvent in 2.2.x or even 2.4.x. If you
think it is possible, post a full config. I think it is impossible,
because focus_change is not sent when there were no any focused window,
even if there is a new focus now. There are many situation when there is
no focus if FocusFollowsMouse is used. I don't know whether this may be
counted as a bug or a feature, but this is how it works in 2.4.x/2.5.x.

Your lines also enforce focus policies on all windows that is not needed
with enter_window/leave_window. I would use NeverFocus for special windows
not FocusFollowsMouse, and FvwmAuto does not work on NeverFocus windows.
Finally I suppose that you suggest either ClickToFocus or SloppyFocus in
the first line, not both, because one overwrites another.

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 15 Apr 2002 21:47:15 +0000

> sure if it's a bug or not...

The lines are ok except of one missing line that you certainly use:

  *FvwmEvent: PassId

The problem with FvwmEvent working on enter_window/leave_window is that
these events are sent when you enter/leave small subwindows too, gtk+
widgets included.

Here is a known problem when Raise/Lower is used, windows may easily
placed so they compete for a place on top forever (i.e. alternately are
raised/lowered until mouse does not leave the region:

  *FvwmEvent-Test: PassId
  *FvwmEvent-Test: enter_window "Selective Raise"
  *FvwmEvent-Test: leave_window "Selective Lower"

  DestroyFunc Selective
  AddToFunc   Selective
  + I WindowId $1 $0

  FvwmEvent FvwmEvent-Test
  #KillModule FvwmEvent FvwmEvent-Test

I also sometimes experienced flickering of the pager labels forever when
using enter_window/leave_window together with Schedule, but now when I
tried hard, I can even sometimes reproduce this with your config above too.

It seems that FvwmEvent with enter_window/leave_window (probably when
using actions other than Raise/Lower too) is problematic, don't use it.

I suggest to continue to discuss this on fvwm-workers list.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 16 Apr 2002 12:17:59 +0200

On Mon, Apr 15, 2002 at 07:52:16PM +0300, Tom Alsberg wrote:
>...

Um, yes.  It's very easy to create a race condition with the
enter and leave events in FvwmEvent.  THere isn't much we can do
about it, though.

Bye

Dominik ^_^  ^_^

---

From: Tom Alsberg <[email-masked]>
Date: Tue, 16 Apr 2002 13:47:48 +0300

> The lines are ok except of one missing line that you certainly use:

Oh, yes... I do have that line... I just forgot to quote it...

> these events are sent when you enter/leave small subwindows too, gtk+

I'm not experienced in this, but isn't there a way to avoid this? I
mean, like disregarding windows not managed by FVWM (I assume FVWM
doesn't manage those small subwindows), or the like?

Also, I don't think this should affect it... Since I'm applying the
Lower and Raise actions in the SelectiveLower/SelectiveRaise functions
only on 4 specific windows...

> tried hard, I can even sometimes reproduce this with your config above too.

Yeah, that happens to me sometimes also...

> using actions other than Raise/Lower too) is problematic, don't use

I suppose since those events exist, they should be somehow usable...
Well, do you have any idea how otherwise I can do what I'm trying to
do? (I was told that's what I should use when FVWM 2.5 was started on
a thread where I asked about it...)

> I suggest to continue to discuss this on fvwm-workers list.
OK...

> Mikhael.

  Thank you, best regards,
  -- Tom

---

From: Tom Alsberg <[email-masked]>
Date: Tue, 16 Apr 2002 13:50:14 +0300

> enter and leave events in FvwmEvent.  THere isn't much we can do

Why can't it be fixed somehow? I mean, what is exactly the cause for
that condition?

  Regards,
  -- Tom

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 16 Apr 2002 15:42:12 +0200

> Why can't it be fixed somehow? I mean, what is exactly the cause for

This can't be fixed in general inside fvwm and/or FvwmEvent
because *your* code causes the race condition.  FvwmEvent can't
know how and when fvwm will react to the enter and leave packets.
Let's assume you have two windows:

         *
 +--------------+
 |A             | 
 |  +---------------+
 |  |B          :   |
 |  |           :   |
 |  |           :   |
 +--|............   |
    |               |
    +---------------+
 
The * marks the pointer position.  Now you drag the pointer 
down into window B, passing over window A.  X generates an enter
event on window A first, then an enter event on window B and a
leave event on window A.  FvwmEvent is informed of these events
and replies with

  Silent SelectiveRaise (A)
  Silent SelectiveLower (A)
  Silent SelectiveRaise (B)

When this actually happens is unpredictable.  Under some
circumstances, fvwm now raises window A while the pointer is
already over B. this causes an enter event on A and a leave event
on B.  Next it raises B, generating enter on B and leave on A.
FvwmEvent replies with "Silent Selective..." and the loop begins
again.  To fix that one would have to synchronize communication
between X, fvwm and FvwmEvent.  On one hand, this is not possible
because fvwm takes input from FvwmEvent and X at the same time and
can not determine which was generated first.  But even if that
were possible, this would slow down FvwmEvent to fvwm
communication so much that the enter and leave events would become
pointless.

All you can do is to very carefully program the functions that do
the raising/lowering.  With the new 'Schedule' and 'Deschedule'
commands it is possible to avoid the race condition.

Bye

Dominik ^_^  ^_^

---

From: "S. Anderson" <[email-masked]>
Date: Tue, 16 Apr 2002 15:02:48 -0600

> lowered when the mouse pointer enters and leaves them...

If your windows are at the edge of the screen, check out 'EdgeCommand'
in the fvwm(cvs) man page. Mabey it can help your problem, on the other
hand it may not help at all. :-)

sa