On Fri, Sep 10, 2010 at 9:13 AM, Andreas Raab <andreas.raab at gmx.de> wrote:

> 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?
>

+1.


>
> 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
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100910/4e9f2fe9/attachment.htm