Subject: BUSY_CURSOR/rxvt selection problem

From: Dominik Vogt <[email-masked]>
Date: Tue, 18 Jan 2000 18:22:49 +0100

I've spent a few days locating the culprit of the rxvt problem
reported recently (if you drag a window fast with the title bar
and cross a rxvt window, the button press often goes through
to rxvt which changes the selection).  The problem showed up
in two steps.

At first it showed up very rarely.  I've narrowed this down two
one specific commit: the one that introduced the busy cursor:

1999-10-30  Olivier Chapuis  [email-masked]

	* NEWS: BusyCursor, EscapeFunc and CursorStyle.
	* fvwm/ConfigFvwmDefaults: add the binding Key Escape A MC EscapeFunc
	* fvwm/builtins.c (wait_func, recapture): Busy cursor stuff
	* fvwm/cursor.{c,h} (cursor_type, default_cursors, CursorStyle,
	  setBusyCursor, myCusorNameToIndex):
	Add CRS_ROOT and ROOT context for CursorStyle. We can use X11 cursor
	name in the CursorStyle command. Busy cursor stuff.
	* fvwm/focus.c (FocusOn): update GrabEm and GrabEm.
	* fvwm/function.{c,h} (func_config, execute_complex_function,
	  DeferExecution):
	New functions BusyCursor and EscapeFunc. Busy cursor stuff.
	* fvwm/fvwm.{c,h} (StartupStuff, InitVariables):
	Some Busy cursor stuff, the new external int GrabPointerState.
	* fvwm/fvwm2.1: BusyCursor and EscapeFunc documentation.
	Update CursorStyle documentation.
	* fvwm/menus.c (MenuInteraction, pop_menu_up): Busy cursor stuff.
	* fvwm/misc.{c,h} (GrabEm, UngrabEm):
	Busy cursor stuff. Grab context bits for GrabPointerState.
	* fvwm/module_interface.c (ExecuteModuleSync):
	Busy cursor stuff and some logic fixes.
	* fvwm/move_resize.c (InteractiveMove, resize_window):
	update GrabEm and UngrabEm.
	* fvwm/module_interface.c (do_execute_module, SendStrToModule,
	  ExecuteModuleSync):
	Comments some not useful (IMHO) UngarbEm for the Busy cursor stuff.
	And ... Busy cursor stuff !
	* fvwm/placement.c (PlaceWindow): update GrabEm and UngrabEm.
	* fvwm/read.c (cursor_control, ReadFile, PipeRead): Busy cursor stuff.
	* fvwm/screen.h (ScreenInfo): BusyCursor

	(added by Mikhael Goikhman)
	* fvwm/ConfigFvwmSetup:
	* fvwm/fvwm2.1:
	* sample.fvwmrc/system.fvwm2rc:
	* sample.fvwmrc/system.fvwm2rc-sample-95:
	Removed xsetroot -cursor_name in initialization functions.

But some time between 10th and 14th of November it got much much
worse.  I coulndn't narrow it down much further yet, but there
are two suspects: the decor_w was introduced in this time and
more work was spent on the BUSY CURSOR patch.

Olivier, I think we urgently need a way to disable the BUSY
CURSOR stuff to narrow down some of the problems.  Could you
please modify all the places you changed so that we can
enable/disable your patches with a #define?

Bye

Dominik ^_^

-- 
Dominik Vogt, Agilent Technologies, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/464-4596, fax: 07031/464-3883, [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: Olivier Chapuis <[email-masked]>
Date: Tue, 18 Jan 2000 23:19:52 +0100

> 1999-10-30  Olivier Chapuis  [email-masked]
[Snip]
> more work was spent on the BUSY CURSOR patch.

I do not see any changes to the BUSY CURSOR patch between 10th and 14th
of November. 

> enable/disable your patches with a #define?

Ok it is done.
A suggestion: may be you can put the last Ungrab(GARB_NORMAL) of the 
function execute_complex_function from function.c after the the while
loop (i.e., just before the WaitForButtonsUp(False);)

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 19 Jan 2000 10:43:45 +0100

> I do not see any changes to the BUSY CURSOR patch between 10th and 14th

Okay, you're right.  I saw your name several times between these
dates, and when I wrote the mail I didn't bother to double check
if it was really related to the BUSY CURSOR patch.  The problem
is probably not related to module communication or the strokefunc
command.

> loop (i.e., just before the WaitForButtonsUp(False);)

What is the improvement you have in mind?

I'm not sure we can do that.  What if you want to do something within
the function that requires that other applications can grab the pointer?

Bye

Dominik ^_^