Subject: Re: FVWM: Focus change and destroy_window event in 2.3.19

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 6 Aug 2000 12:09:02 +0300

On 30 Jun 2000 13:19:11 +0200, Adam Tla/lka wrote:
> 
> Hi,
> 
> I am using in my .fvwm2rc :

Here is the same configuration that you posted, but a bit formatted to be
more clear, not to interfere with other FvwmEvent's and to be able to be
re-Read as many times as needed.

DestroyFunc CurrentRaiseWarp
AddToFunc   CurrentRaiseWarp
+ I Current (!Visible) Raise
+ I WarpToWindow 50 16p
     
DestroyFunc GoToLast
AddToFunc   GoToLast I Prev (CurrentPage !Iconic) FlipFocus
     
DestroyFunc WasActive
AddToFunc   WasActive
+ I DestroyFunc GoToLast
+ I AddToFunc   GoToLast I Nop
  
DestroyFunc LastActive
AddToFunc   LastActive
#+ I WindowList
+ I Current (CurrentPage !Iconic) Function WasActive
+ I Function GoToLast
+ I Current (CurrentPage !Iconic) Function CurrentRaiseWarp
+ I DestroyFunc GoToLast
+ I AddToFunc   GoToLast I Prev (CurrentPage !Iconic) FlipFocus

DestroyFunc WarpToNew
AddToFunc   WarpToNew
+ I WindowId $0 WarpToWindow 50 16p

DestroyModuleConfig MyEvent*
*MyEventPassID
*MyEventDelay 0
*MyEventCmd Function
*MyEvent add_window WarpToNew
*MyEvent destroy_window LastActive

KillModule  FvwmEvent MyEvent
Module      FvwmEvent MyEvent

> to obtain focus to any new created window and get focus to last active one
> while current active is deleted. First works ok for me but second does not.
> I observe that before event is activated the window under the pointer 
> position is focused (it's not the last active one in this case)
> so list order is changed and then event function is useless. 
> I am using SloppyFocus.
> Strange because it worked properly in 2.2.4 version.

Your observation is correct. LastActive is called after a window under
the pointer gets a focus, which makes destroy_window event useless in your
case. This is clearly seen if you uncomment the WindowList line.

I can see that, like in 2.2.4, M_DESTROY_WINDOW is broadcasted, i.e. added
to a queue, *before* the focus games on a window under a pointer.

Ok, I have fixed this problem by making SetSyncMask on all messages in
FvwmEvent.

For some reason SetSyncMask(fd, M_DESTROY_WINDOW), i.e. 1<<7, has no
effect for me, but SetSyncMask(fd, 1<<31) does the fix! I am confused.
Don't forget to SendUnlockNotification(fd) if you want to try this.

Related issue. FvwmEvent does not SetMessageMask, so it always gets all
events, which is by itself is not optimal; making all of them synchronized
can be a little slow. Any thoughts?

Regards,
Mikhael.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 19 Aug 2000 22:02:58 +0300

> Ok, I have fixed this problem by making SetSyncMask on all messages in

This fix (SetSyncMask on all messages) was actually not a relable one.

> effect for me, but SetSyncMask(fd, 1<<31) does the fix! I am confused.

On some level, 0x80000000 is converted to 0x7fffffff, which is buggy
regardless of signed/unsigned arithmetics. But this is not directly
related to the mentioned problem.

The problem is in this line of PositiveWrite in module_interface.c:

  if ((SyncMask[module] & ptr[1]) && !myxgrabcount)

So, even if a message is set to be synchronized, still it's not guaranteed
that this will be the case. For example, M_DESTROY_WINDOW is always sent
inside of MyXGrab/MyXUnGrab. I removed the myxgrabcount condition bit,
this together with synching on destroy_window fixes the original problem.
I understand this may cause problems, but I see no other solution. I have
tested several cases, like 2 FvwmAnimate, 2 FvwmEvent and see no problems.
I will restore the original condition if there are ones.

Regards,
Mikhael.