On 23 May 2013 21:26, Chris Muller <asqueaker at gmail.com> wrote:
> 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.
>
> 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!

Well, after I ripped out the Morphic stuff (inbox, Monticello-fbs.545,
please comment!) MCTool still looks useful, as a place where default
values live. In other words, it kind've plays the role of a mini
theme.

I think I can see a few more things that could go, like #perform:orSendTo:.

frank

> On Thu, May 23, 2013 at 12:40 PM, Frank Shearar <frank.shearar at gmail.com>
> wrote:
>>
>> On 23 May 2013 07:46, Balázs Kósi <rebmekop at gmail.com> wrote:
>> > Monticello already uses ToolBuilder if it's
>> > present (see MCTool>>buildWindow), so the repository inspector
>> > responsiveness is fixed to some extent.
>>
>> Eek! ToolBuilder should be (*) the only package to use Morphs. Is
>> there any value in keeping MCTool's
>> build-if-ToolBuilder-or-roll-own-if-not?
>>
>> Two ways of building UIs means they _will_ diverge. ToolBuilder's the
>> correct way to build a UI, so the fallback position can only rot.
>>
>> frank
>>
>> (*) for standard tools especially!
>>
>
>
>
>