Re: Notification: incoming/876
On Thu, Jun 13, 2002 at 11:56:43PM +0200, Jan Echternach wrote: On Wed, Jun 12, 2002 at 12:02:53AM +0200, Jan Echternach wrote: 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. 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(): [snip] I've fixed it again. 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 ... This bug is still there, even in fvwm-2.4.8 with the workaround I've found. 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 ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/876
On Thu, Jun 13, 2002 at 11:56:43PM +0200, Jan Echternach wrote: On Wed, Jun 12, 2002 at 12:02:53AM +0200, Jan Echternach wrote: 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. 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, The frame window is the big window that contains the client window (-w) and all the decorative windows. 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. 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 PROTECTED] 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/876
On Wed, Jun 12, 2002 at 12:02:53AM +0200, Jan Echternach wrote: 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. 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. 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 ... This bug is still there, even in fvwm-2.4.8 with the workaround I've found. -- Jan fortune: can't load library '/libc.so.4' No such library. -- 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/876
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. -- 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/876
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 have noticed a short screen flicker when the pointer is moved out
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 ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/876
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 have noticed a short screen flicker when the pointer is moved out
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.
Style * ForeColor Black
Style * BackColor DarkOliveGreen4
Style * HilightFore Black
Style * HilightBack indian red
Style * BorderWidth 5, HandleWidth 5
Style * FvwmBorder # MWMBorder
Style * FvwmButtons
HideGeometryWindow Never
SnapAttraction 0 SameType Screen
OpaqueMoveSize 100
Style * WindowShadeSteps 0
EdgeScroll 100 100
EdgeResistance 250 20
EdgeThickness 1
Style * MinOverlapPlacement
Style * MWMFunctions
Style * MWMDecor
Style * HintOverride
Style * OLDecor
Style * DecorateTransient, RaiseTransient, LowerTransient, StackTransientParent
--
Jan fortune: can't load library '/libc.so.4'
No such library.
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/876
On Mon, May 27, 2002 at 02:19:16AM +0200, Dominik Vogt wrote: Should be fixed with the next release. Could you please try the latest CVS code or tomorrow's snapshot and report back if the problem goes away? I have tried fvwm-snap-20020528.tar.gz. The colormap problem has disappeared, but now the netscape window has the effect of SloppyFocus (other windows like xterm don't have it, and with fvwm-2.4.7 no window has SloppyFocus). I've used the same .fvwm2rc file with both fvwm versions. BTW, my keyboard bindings (e.g. Key Left A 3 Scroll -100 0) don't work with fvwm-snap-20020528. -- Jan fortune: can't load library '/libc.so.4' No such library. -- 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/876
On Wed, May 29, 2002 at 12:04:32AM +0200, Jan Echternach wrote: I have tried fvwm-snap-20020528.tar.gz. The colormap problem has disappeared, but now the netscape window has the effect of SloppyFocus (other windows like xterm don't have it, and with fvwm-2.4.7 no window has SloppyFocus). I've used the same .fvwm2rc file with both fvwm versions. 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. So it looks as if netscape still has the focus at the first glance, but F1, for example, does open fvwm's builtin menu, and upon showing the popup window (or when the pointer is moved into another window), the normal colormap is restored and the desktop looks normal again. -- Jan fortune: can't load library '/libc.so.4' No such library. -- 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/876
On Wed, Apr 17, 2002 at 05:34:05PM -0500, fvwm-bug wrote: FVWM Bug Tracking notification new message incoming/876 Full_Name: Jan Echternach Version: 2.4.7 CVS_Date: OS: Linux X_Server: XFree86 3.3.6 Submission from: (NULL) (62.104.208.83) Szenario: netscape uses a private colormap. A transient window is opened (e.g. the Find dialog with Alt+F), also with a private colormap. This new window gets the focus even if the pointer (FocusFollowsMouse) is not inside it. Esc is pressed to close the transient window. Case 1: Pointer is in the transient window: no problem. Case 2: Pointer is outside the transient window, but inside the main netscape window: The colormap of the main window won't be restored properly, even though it gets the focus and the pointer is inside it. Should be fixed with the next release. Could you please try the latest CVS code or tomorrow's snapshot and report back if the problem goes away? Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Notification: incoming/876
FVWM Bug Tracking notification new message incoming/876 Message summary for PR#876 From: [EMAIL PROTECTED] Subject: Private colormap not restored Date: Wed, 17 Apr 2002 17:34:05 -0500 0 replies 0 followups ORIGINAL MESSAGE FOLLOWS From [EMAIL PROTECTED] Wed Apr 17 17:34:05 2002 Received: from karazm.math.uh.edu ([129.7.128.1]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 16xy05-0005Es-00 for [EMAIL PROTECTED]; Wed, 17 Apr 2002 17:34:05 -0500 Received: from malifon.math.uh.edu (IDENT:[EMAIL PROTECTED] [129.7.128.13]) by karazm.math.uh.edu (8.9.3/8.9.3) with ESMTP id RAA08548 for [EMAIL PROTECTED]; Wed, 17 Apr 2002 17:34:05 -0500 (CDT) From: [EMAIL PROTECTED] Received: from localhost ([127.0.0.1] ident=65534) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 16xy05-0005Eo-00 for [EMAIL PROTECTED]; Wed, 17 Apr 2002 17:34:05 -0500 To: [EMAIL PROTECTED] Subject: Private colormap not restored Message-Id: [EMAIL PROTECTED] Date: Wed, 17 Apr 2002 17:34:05 -0500 Full_Name: Jan Echternach Version: 2.4.7 CVS_Date: OS: Linux X_Server: XFree86 3.3.6 Submission from: (NULL) (62.104.208.83) Szenario: netscape uses a private colormap. A transient window is opened (e.g. the Find dialog with Alt+F), also with a private colormap. This new window gets the focus even if the pointer (FocusFollowsMouse) is not inside it. Esc is pressed to close the transient window. Case 1: Pointer is in the transient window: no problem. Case 2: Pointer is outside the transient window, but inside the main netscape window: The colormap of the main window won't be restored properly, even though it gets the focus and the pointer is inside it. -- 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
