<br><br><div class="gmail_quote">On Fri, Sep 10, 2010 at 9:13 AM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Florin -<br>
<br>
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:<br>
<br>
ToolBuilder>>openDebugger: aSpec<br>
"Build and open a debugger from the given spec.<br>
Answer the widget opened. Subclasses can override this<br>
method if opening a debugger has specific requirements<br>
different from opening other widgets."<br>
<br>
^self open: aSpec<br>
<br>
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).<br>
<br>
What do you think?<br></blockquote><div><br></div><div>+1.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Cheers,<br><font color="#888888">
- Andreas</font><div><div></div><div class="h5"><br>
<br>
<br>
<br>
On 9/10/2010 6:37 AM, Florin Mateoc wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 9/10/2010 9:16 AM, Florin Mateoc wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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<br>
the previously running activeControllerProcess is the process under debug<br>
</blockquote>
Sorry about all these self-replies. I just wanted to make one more edit before I run to work, because I think it is<br>
important documentation:<br>
<br>
<br>
What we want to make sure, in the general case, is not so much that we kill the active process but the currently running<br>
activeControllerProcess, and allow the newly created controller loop to become the new activeControllerProcess. We want<br>
to make sure that one and only one controller (or screen) loop (ui process) runs at all times (except very briefly<br>
during transitions from one ui process to the other).<br>
<br>
The debugger is different in the sense that, while it does take over as the activeController upon its open, in those<br>
cases when the currently running activeControllerProcess is the process under debug, it only wants to suspend it.<br>
It does want to terminate the currently running activeControllerProcess otherwise (then the debugger behaves like any<br>
other "normal" ui controller).<br>
<br>
There are probably many different ways to achieve this. E.g. a lot of these scheduling methods in VW are guarded with a<br>
"activeControllerProcess notNil and: [activeControllerProcess == Processor activeProcess]". The same check is constantly<br>
done in the controller loop. Squeak doesn't have these checks, so it works with a lot of assumptions about which methods<br>
are called from which processes<br>
<br>
<br>
Florin<br>
<br>
<br>
</blockquote>
<br>
<br>
</div></div></blockquote></div><br>