Hi guys,

Marcel, we had a good discussion in the other thread (The Inbox:
System-cmm.1059.mcz) which led to this temporary solution acceptable
with at least Jakob and I.

> The Tools menu is *not* about installing tools but starting them.

I was under the assumption Metacello has a browser and intend for that
menu item to open a Metacello browser after the #ensureMetacello.
That preserves what Jakob wanted while one-upping the IDE
functionality we have today.

> Also, the "Do" menu is *not* for newcomers but for somewhat experienced programmers that are able to write and use small scripts to optimize the own workflow.

Rather than disagree about what it is, perhaps we can agree that it
_isn't_ a place for configuration within release image.  These tools
deserve a better place than the Do menu, and Squeak deserves to have
one unified way to load anything.  This takes it from three to two.

> Just look at what is already in the Tools or Do menu and you can easily see these inherent characteristics. Please try to explain your decisions with more details. What is your perspective on the Tools menu?

My perspective is that SCM "tools" like Simple and Dual Change sorter,
Monticello and Monticello Configurations are available under the Tools
menu.  It therefore makes sense to me that the next-level SCM tool
built on top of Monticello would be right there, too.  Does Metacello
have a browser at all, or will it?

> For newcomers, they can evaluate a snippet in the workspace that includes installing such infrastructure. Just copy-and-paste from a readme.md or similar. Quite simple.

Agreed, and I would even store such snippets in SqueakMap.

because then I could add additional entries that contained whatever is
in the README's, and then, instead of coming back from getting coffee
to ONLY have Metacello loaded, I could have _everything_ loaded.  But
that's not my business except to the extent I want Squeak release
images to have the only the right tools in only the right places, so
its not too confusing.

> In the long term, we should find ways to ship such infrastructure in releases without spoiling the (development) trunk.

I hope you mean as dynamically-loadable modules.  The release images
are too big, IMO, we need to eventually try to get some things out
(Etoys) so we can make room to bring more appropriate (core) stuff in.

> Best,
> Marcel

Best,
  Chris