FVWM Bug Tracking notification
new message incoming/823
Message summary for PR#823
From: [EMAIL PROTECTED]
Subject: Unexplainable delays when popping up windows in GIMP
Date: Tue, 04 Dec 2001 04:46:20 -0600
0 replies 0 followups
====> ORIGINAL MESSAGE FOLLOWS <====
>From [EMAIL PROTECTED] Tue Dec 04 04:46:21 2001
Received: from karazm.math.uh.edu ([129.7.128.1])
by malifon.math.uh.edu with esmtp (Exim 3.20 #1)
id 16BD5h-00050l-00
for [EMAIL PROTECTED]; Tue, 04 Dec 2001 04:46:21 -0600
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 EAA24061
for <[EMAIL PROTECTED]>; Tue, 4 Dec 2001 04:46:20 -0600 (CST)
From: [EMAIL PROTECTED]
Received: from localhost ([127.0.0.1] ident=65534)
by malifon.math.uh.edu with esmtp (Exim 3.20 #1)
id 16BD5g-00050h-00
for [EMAIL PROTECTED]; Tue, 04 Dec 2001 04:46:20 -0600
To: [EMAIL PROTECTED]
Subject: Unexplainable delays when popping up windows in GIMP
Message-Id: <[EMAIL PROTECTED]>
Date: Tue, 04 Dec 2001 04:46:20 -0600
Full_Name: Petr Mladek
Version: 2.4.3
CVS_Date:
OS: SuSE Linux 7.3
X_Server: XFree86 4.1.0
Submission from: (NULL) (213.210.157.162)
Hi,
anybody found the problem with gimp (1.2.2) and fvwm (2.4.3).
I reproduced this bug when:
1. fvwm was configured to manual window placement:
I had next lines in system.fvwm2rc:
Style "*" SmartPlacement, RandomPlacement, ActivePlacement
Style "*" NoPPosition
With this configuration is important that actual desctop is full
and new window will be placed manually.
2. The action with gimp (1.2.2):
If I used the "Color picker" and clicked on a pixel, the new color
appeared
immediately in the foreground area of GIMP's main window, but the
additional window to display the RGB components of the color took several
seconds to appear.
The reason of the problem:
When anybody push the left mouse button in gimp and the tool
"Color Picker" is selected then the gimp grab the mouse pointer
and in the same time it wants to open additional window to
display RGB components. The problem is when fvwm wants to
place this window manually because fvwm tries to grab the mouse
pointer also.
Solution:
Fvwm tries to grab the mouse pointer several seconds. I think that
this time should be several miliseconds (50ms).
My opinion:
Fvwm is "dead" when it tries to grab the mouse pointer. Only one
window has focus and other windows are cramped. In this situation
is deadlock very probable. I think that 50ms for dead lock
is good acceptable for user and it is also safe for slower applications
and computers.
My patch:
--- fvwm/misc.c
+++ fvwm/misc.c
@@ -149,7 +149,7 @@
return False;
default:
grab_win = Scr.Root;
- rep = 500;
+ rep = 6;
break;
}
--- fvwm/placement.c
+++ fvwm/placement.c
@@ -839,9 +839,8 @@
else
{
/* couldn't grab the pointer - better do something */
+ CleverPlacement(tmp_win, &screen_g, &xl, &yt, pdeltax, pdeltay,
1);
XBell(dpy, 0);
- xl = 0;
- yt = 0;
}
if (flags.do_honor_starts_on_page)
{
I also used CleverPlacement insted of [0,0] position.
BTW: Thanks for your effort, the fvwm is very good project.
With greetings,
Petr Mladek
software developer
---------------------------------------------------------------------
SuSE CR, s.r.o. e-mail: [EMAIL PROTECTED]
Drahobejlova 27 tel:+420 2 9654 2373
190 00 Praha 9 fax:+420 2 9654 2374
Ceska republika http://www.suse.cz
--
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]
