<div dir="ltr">I think this is because, back in 2004 when Avi made Monticello, we did not have the trunk process we have now, and it was easier to diverge than to try to integrate.<div><br></div><div style>I know of no reason we still need MCTool. But if we do get rid of it, let's throw that modal junk out the window too!</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 23, 2013 at 12:40 PM, Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 23 May 2013 07:46, Balázs Kósi <<a href="mailto:rebmekop@gmail.com">rebmekop@gmail.com</a>> wrote:<br>
> Monticello already uses ToolBuilder if it's<br>
> present (see MCTool>>buildWindow), so the repository inspector<br>
> responsiveness is fixed to some extent.<br>
<br>
Eek! ToolBuilder should be (*) the only package to use Morphs. Is<br>
there any value in keeping MCTool's<br>
build-if-ToolBuilder-or-roll-own-if-not?<br>
<br>
Two ways of building UIs means they _will_ diverge. ToolBuilder's the<br>
correct way to build a UI, so the fallback position can only rot.<br>
<br>
frank<br>
<br>
(*) for standard tools especially!<br>
<br>
</blockquote></div><br></div>