Hi,

> This has the nice property of capturing single chunks of interaction.

To me this sounds precisely like what you get when you would simply set your
brick as the current mouse focus. Have you tried this? Might be easier to
figure out than a multi-threaded version.

> The dispatcher also captures all events in an interaction in 
> a separate collection for examination and playback later.
> Now its possible to stick a halt in a brick event handler and 
> actually debug it since you're debugging a different process from
> the main UI one.
> Another nifty thing I added is a halt latch - there's a flag that you 
> set to cause a one-shot halt.  When the flag is tested it is 
> simultaneously cleard.

Ah, you mean like Object>>doOnlyOnce: and Object>>reArmOneShot? Here is a
pattern which I often use (in terms of those two methods):

normalMethod

	self doOnlyOnce:[
		[self halt
		self tryMyWeirdMethod] ensure:[self reArmOneShot].
	].

What does this do? The first time the system gets there, it'll halt and I
can (from the debugger) step into my new version of the method and walk
through it, programming happily along. If I get something wrong (or make a
mistake otherwise) I just close the debugger which only then will get me a
new debugger for continuing to program.

When I am mostly confident with the method, I simply remove the "self halt",
and leave it running for the entire system. If something goes wrong, it'll
fall back to the original implementation during the debug session.

I found this to be the most useful technique for debugging UI problems.

Cheers,
  - Andreas