Well, seemed to me for 2 people you got quite a lot done, so it seems to
me you're getting along fine. Of course, there's work enough in cleaning
morphic for 10 people, but I'm sure more will join in.

BTW, if some parts of the task are less interesting than others, focus
on the interesting ones, we're happy if you're happy :-) 

I wonder if you find this interesting - the class category
Morphic-Experimental sounds to me unessential to Morphic. But looking at
the reference graph using SpT, I see that actually, Morphic-Kernel does
depend on it in a few ways. The *PropertiesMorph classes are referenced
by Morph. This requires some sleuthing as to whether the *PropertyMorphs
should actually be in the Squeak core (in which case, they should be
moved out of the category *Experimental), or that they should be made
somehow optional extensions, which would require some design solution.

I'm building a test+tool suite that surfaces this kind of issues for
Morphic specifically, and Squeak in general. For example, I did -

mma_MultiModuleAnalyzer onCategoriesWithPrefix: 'Morphic'.
mma allShortestPathsFromPackage: (mma packageDefiningClass: Morph) to:
(mma packageDefiningClass: TextPropertiesMorph)

and got a whole list of paths full of design darkness. For example,
TheWorldMenu knows the Flaps (sigh), the Flaps know the
ProjectNavigatorMorph (Huh? flaps should be pluggable mechanism, and
nothing more) which knows the EToyProjectHistoryMorph, which is a bit
weird since the latter is in Experimental.

Which suggests already two (IMHO) interesting redesign and cleanup
projects -
1. How do we make Flaps pluggable enough to express everything it knows
about other classes, without hardcoding?
2. Same for TheWorldMenu.

Daniel

diegogomezdeck at consultar.com wrote:
> Hi Daniel & list...
> 
> The very first point to attack is to get more people on MCPTeam. We was 5
> in the beggining and now we're only 2 of us.
> 
> We're planning to call (again) for help.  To cleanup the morph part is a
> big job (and boring) and the "future" looks not so good with only 2 of us.
> 
> After this point, we have a set of really-small-changes to do (basically
> some changes we rollback to avoid conflicts).  And then our plan is to
> discuss in public the next steps.
> 
> Cheers,
> 
> Diego
> 
> > Hi MCP, everybody.
> >
> > Now that we have the first MCP stuff in the image, I'm sure I'm not the
> > only one curious about your intended next steps. I'm very happy with
> > the changes done so far, and also have some suggestions about where to
> > go next.
> >
> > One of the big problems with understanding Morphic is that, as one of
> > you guys said a couple of weeks ago, it's limits are unclear. This is
> > because the framework is often codependent with it's clients (the
> > morphic applications and extensions).
> >
> > This is an area which I would be very happy if you decide to attack,
> > because every application which is extricated from this mess will make
> > Morphic clearer for all of it's users, in addition to users of that
> > specific application.
> >
> > It is also an area in which I hope SpaghettiTracer can significantly
> > help locate and resolve problems, and I'd be glad to help you try it
> > out.
> >
> > Daniel