Daniel,

> [Vague limits of morphic]
>
> two answers -
> 1. Theoretically, and IMO, and an important part of your job is to
> bring us there, Morphic, as a framework, should have pretty clear
> limits. There should be a set of classes that are all needed for a
> Morphic UI, but don't depend on anything. And everything else is an
> extension. Obviously applications (Alice Games) are not in. Even Menus,
> PLMs and friends are probably extensions, in the sense that they don't
> are not intrinsically needed by morphic (just by many applications).
> My theory about how to trace and solve this kind of issue is that the
> unclear borders are marked by cycles - when the framework references
> applications that use it, that's pathological. So it should be useful
> to find the cycles and cut them. That's what SpaghettiTracer does. If
> you want to give it a shot, let me know and I'll explain more.

This can be done, but we have to wait for all the removals first.

> 2. On another level (where do your patches go, when you're not changing
> big structure yourself), you should keep tabs on removals and other
> ongoing refactorings that have a Morphic aspect (even Celeste, to a
> small extent), and when you affect something that went into the module,
> as people have said, send the patches to the maintainers. IOW, try to
> use the de facto package borders.

I agree with you that it could be great. But, as you know, these ideas put
stones in our MCP road.  Each package removal make our work more hard.  Or
you have something in mind that can help here?

The less-pain way should have been: First the cleaning and then the
removals.

> Daniel

Diego