Yep - this is a major problem.  I'm working on event handling for 
Bricks.  I want a bottom up event dispatching model like every other UI 
toolkit I've ever used (Morphics is sort of top down).  To this end I 
have:

overridden processEvent:dispatcher: to substitute a 
BricksEventDispatcher.
BrickEventDispatcher adds itself to the hand as an event listener and 
puts all events into a SharedQueue.
It then forks a process to pull and process all the events in the queue.
The dispatcher unregisters itself as a listener when the mouse leaves 
the brick with the mouse up (otherwise its tracking potential clicks).
This has the nice property of capturing single chunks of interaction.

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.

Using this, you can do something to a brick, open an inspector on its 
dispatcher and evaluate "self replay".  This sets the halt latch on the 
main loop and re-queue's all the events of the last interaction chunk.  
The debugger opens and voila - I can debug event dispatching without 
hanging my image.

Only top-level bricks get dispatchers - bricks always return their 
owner's dispatcher unless the owner isn't a brick - then they create 
one themselves.

Its working fairly well.  Lots of tweaking to do yet but at least I can 
see what's going on.

-Todd Blanchard

On Wednesday, July 30, 2003, at 05:51 AM, Daniel Vainsencher wrote:

> Jesse Welton <jwelton at pacific.mps.ohio-state.edu> wrote:
>> The time distribution is part of the planned integration of
>> SendTreeExplorer with MessageTally.  Adding a code pane is also
>> planned.
> Cool.
>
>> It's not currently possible.  I think it's possible to add this, but I
>> don't know how useful it would be.  Interactively debugging Morphic
>> processes from within Morphic is tremendously difficult because many
>> things (particularly layout) are constantly being completed by the UI
>> process before you can trace them in the debugger.
>
> Ah, that makes sense, I hadn't thought of the UI process interfering
> with debugged UI processing. Maybe Neds idea of debugging Morphic from
> MVC could be relevant here, though I don't know how complicated that
> would be to set up.
>
> Daniel
>