Hi Florin -

Thanks for all the info. Reading through it, it sounds to me that the 
real "specialty" here is opening a debugger. Which seems quite 
reasonable to me because debuggers have special needs. So maybe we 
should add a specific open method to ToolBuilder that is specifically 
used for opening debuggers? I.e., something like:

ToolBuilder>>openDebugger: aSpec
	"Build and open a debugger from the given spec.
	Answer the widget opened. Subclasses can override this
	method if opening a debugger has specific requirements
	different from opening other widgets."

	^self open: aSpec

And then MVCToolBuilder can implement the appropriate open method. This 
would make the interface more intentional, i.e.,describing what are we 
trying to do (open a debugger), instead of describing how we do it (not 
terminating the MVC scheduler process).

What do you think?

Cheers,
   - Andreas



On 9/10/2010 6:37 AM, Florin Mateoc wrote:
>   On 9/10/2010 9:16 AM, Florin Mateoc wrote:
>> The debugger is different in the sense that, while it does take over as the activeController upon its open, it only wants to suspend the previously running activeControllerProcess in those cases when
>> the previously running activeControllerProcess is the process under debug
> Sorry about all these self-replies. I just wanted to make one more edit before I run to work, because I think it is
> important documentation:
>
>
> What we want to make sure, in the general case, is not so much that we kill the active process but the currently running
> activeControllerProcess, and allow the newly created controller loop to become the new activeControllerProcess. We want
> to make sure that one and only one controller (or screen) loop (ui process) runs at all times (except very briefly
> during transitions from one ui process to the other).
>
> The debugger is different in the sense that, while it does take over as the activeController upon its open, in those
> cases when the currently running activeControllerProcess is the process under debug, it only wants to suspend it.
> It does want to terminate the currently running activeControllerProcess otherwise (then the debugger behaves like any
> other "normal" ui controller).
>
> There are probably many different ways to achieve this. E.g. a lot of these scheduling methods in VW are guarded with a
> "activeControllerProcess notNil and: [activeControllerProcess == Processor activeProcess]". The same check is constantly
> done in the controller loop. Squeak doesn't have these checks, so it works with a lot of assumptions about which methods
> are called from which processes
>
>
> Florin
>
>