Subject: Re: Notification: incoming/876

From: Dominik Vogt <[email-masked]>
Date: Mon, 3 Jun 2002 19:19:54 +0200

On Thu, May 30, 2002 at 12:22:42AM +0200, Jan Echternach wrote:
> On Wed, May 29, 2002 at 02:04:06PM +0200, Dominik Vogt wrote:
> > > That diagnosis was too quick.  The netscape window actually loses the
> > > focus as it should, but the color map of the root window is not restored.
> 
> > Can you please give me step by step instructions to reproduce the
> > problem, including the relevant config lines?  I don't know how to
> > test this in the first place, but I think the colour map focus and
> > the keyboard focus should stay in the same window.
> 
> Open a window (e.g. "netscape -install", "xv -owncmap"), move pointer into
> window, move pointer out of window (to the root window).  Now the xv or
> netscape window has its color map still installed (i.e. it looks good,
> the rest of the screen is garbled), but the application's key bindings
> are no longer active ('q' doesn't quit xv etc.).  The root window's key
> bindings are active instead (e.g. F1 opens fvwm's builtin menu).

I can reproduce this.  Since you didn't include any focus policy
or colormapfocus command, I assume you are using the defaults:

  Style * MouseFocus
  ColormapFocus FollowsMouse

It's correct that the window does not receive keyboard input in
this case, but the colormap should always be restored to the root
colormap.  Since it depends on how fast you move the pointer, I
guess the reason is that the map is restored properly if the
pointer does not enter the window border first.  I'll take care of
this problem.  Other than that, the behaviour is correct.  From
what you write I assume you might be happier with

  Style * SloppyFocus
  ColormapFocus FollowsFocus

though.

> I have noticed a short screen flicker when the pointer is moved out
> of an xv window to its border or title bar.

I don't see this, but it sounds as if the root colormap is
restored for a moment before the xv colormap is activated again.
Perhaps I can see something with some debug messages.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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: Dominik Vogt <[email-masked]>
Date: Mon, 3 Jun 2002 20:59:58 +0200

On Thu, May 30, 2002 at 12:22:42AM +0200, Jan Echternach wrote:
> of an xv window to its border or title bar.  And if the pointer is
> moved very quickly out of the window, the root window's color map _is_
> restored properly.  The netscape window doesn't show this behaviour.

Should all be fixed now.

Bye

Dominik ^_^  ^_^

---

From: Jan Echternach <[email-masked]>
Date: Wed, 12 Jun 2002 00:02:53 +0200

Hi,

I've tried fvwm-snap-20020607, and the root colormap is restored properly
again.  But the old bug is also back: Closing Netscape's "Find" window
with ESC doesn't restore Netscape's colormap if the pointer is inside
the Netscape window, but outside the "Find" dialog.

Furthermore, I've tried "ColormapFocus FollowsFocus" (instead of the
default "FollowsMouse").  Neither of the bugs I've experienced with
"FollowsMouse" appears with "FollowsFocus", but there is a different bug
instead: Moving a window with FvwmPager installs that window's colormap.
For example, moving an "xv -owncmap" window leaves the screen garbled,
even though the pointer never leaves the pager window and the xv window
isn't even in the current viewport before or after moving it.  Moving an
xterm with the pager installs the correct colormap again ...

-- 
Jan                           fortune: can't load library '/libc.so.4'
                                      No such library.

---

From: Jan Echternach <[email-masked]>
Date: Thu, 13 Jun 2002 23:56:43 +0200

> the Netscape window, but outside the "Find" dialog.

Same with fvwm-2.4.8.

I've discovered that HandleEnterNotify() is only called with Netscape's
"frame" window in this situation, not with the real window.  Output from
a fprintf() at the beginning of HandleEnterNotify():

  ewp->window=0x8000a0, Event.xany.window=0x8000a0, Tmp_win->w=0x14003ae

If the pointer was inside the transient "Find" window before closing it:

  ewp->window=0x8000a0, Event.xany.window=0x8000a0, Tmp_win->w=0x14003ae
  ewp->window=0x14003ae, Event.xany.window=0x14003ae, Tmp_win->w=0x14003ae

If the pointer is moved onto the title bar:

  ewp->window=0x8000a1, Event.xany.window=0x8000a1, Tmp_win->w=0x14003ae

I've no idea what this Tmp_win->frame window is, or why there is sometimes
one EnterNotify event and sometimes two.  But changing

  Event.xany.window == Tmp_win->w

to

  Event.xany.window == Tmp_win->w || Event.xany.window == Tmp_win->frame

near the end of HandleEnterNotify() seems to fix (or work around)
the problem.

> xterm with the pager installs the correct colormap again ...

This bug is still there, even in fvwm-2.4.8 with the workaround I've
found.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 14 Jun 2002 11:53:00 +0200

On Thu, Jun 13, 2002 at 11:56:43PM +0200, Jan Echternach wrote:
> I've no idea what this Tmp_win->frame window is,

The frame window is the big window that contains the client window
(->w) and all the decorative windows.

> or why there is sometimes

I'd rather not modify the EnterNotify handling code.  It's rather
touchy at the moment.  And it shouldn't be necessary either.  In
the situation you describe, no EnterNotify events are generated
because the pointer doesn't change windows.

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-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 18 Jun 2002 12:32:06 +0200

> a fprintf() at the beginning of HandleEnterNotify():
[snip]

I've fixed it again.

> This bug is still there, even in fvwm-2.4.8 with the workaround I've

That's not a bug.  Moving a window in the pager gives it the focus
and because of "ColormapFocus FollowsFocus" also the colourmap
focus.  It would be nice if this were configurable in the pager.

Bye

Dominik ^_^  ^_^