On 30 June 2013 14:03, David T. Lewis <lewis at mail.msen.com> wrote:
> On Sun, Jun 30, 2013 at 11:42:01AM +0100, Frank Shearar wrote:
>> On 5 June 2013 13:35, Frank Shearar <frank.shearar at gmail.com> wrote:
>> > On 5 June 2013 13:20, David T. Lewis <lewis at mail.msen.com> wrote:
>> >>
>> >> I don't know if making a package like Tools fully independent of Morphic
>> >> and ST80 is a practical goal. There are also extensive dependencies of
>> >> Tools on Morphic. If the idea is to make Tools fully independent of the
>> >> Morphic/MVC user interfaces, it looks to me like this would be a big
>> >> challenge.
>> >
>> > I think it should be. Specifically, Tools should only depend on
>> > ToolBuilder-Kernel.
>>
>> One way to break this Tools->ST80 dependency is adding a new package,
>> ST80Tools. This would contain the ST80 specific extensions. It makes
>> things slightly more complicated for loading/unloading MVC, in that
>> "unload" would mean "unload ST80 and any of its associated packages
>> (currently just ST80Tools)", and similarly for loading.
>>
>> frank
>
> That seems like a reasonable approach. I think it would be important to
> take the same approach for both MVC and Morphic, so we could eventually
> have for MVC:
>
>   ST80-Controllers    \
>   ST80-Editors         \
>    ...                  >  - current ST80 package
>   ST80-Views           /
>   ST80-ToolBuilder    /
>   ST80Tools                - new ST80Tools package
>
> And for Morphic:
>
>   Morphic-Balloon     \
>   Morphic-Basic        \
>    ...                  >  - current Morphic package
>   Morphic-Worlds       /
>   Morphic-ToolBuilder /
>   MorphicTests             - current MorphicTests package
>   MorphicTools             - new MorphicTools package
>
> Is that right?

Yes, that's exactly right. We don't have a MorphicTools only because
we haven't needed one - Tools has no extensions to Morphic classes.

frank

> Dave
>
> p.s. I've been trying for a *long* time to get the debugger working in MVC
> again. I think I almost have it working now, and hope to be able to submit
> some fixes before too much more time goes by. It turns out to be rather
> tricky to debug the control loop in MVC, and fixing the debugger without
> the assistance of a debugger has proven something of a challenge as well.
>
>