> On Tue, May 12, 2015 at 3:22 AM, marcel.taeumel <Marcel.Taeumel at hpi.de>
> wrote:
>> Hey, I do account for all of those. It might only be a slip because the
>> documentation is poor. :P
>>
>> As for Message Names, it should be built with ToolBuilder to also work
>> in
>> MVC. So that rules out (!) all Morph-specific features. What lies in the
>> Tools package, must not assume Morph API.
>
> Well, I really don't understand that logic.  There is already very
> little that can be done in a MVC project today compared to a Morphic
> project, and I find it hard to believe MVC cannot have a field which
> does something when Return is pressed anyway.  And if its true why not
> improve MVC than restrict Morphic-based UI's?

If you are only every going to have one flavor of UI framework, then you
do not need a ToolBuilder in the first place. If you *do* want to have a
ToolBuilder, then you had better make sure that it works at some suitable
level of abstraction. In practice this means applying it to more than one
flavor of UI.

I would like to think that we might have more flavors of UI technology in
the future (Juan's Morphic3, touch devices, Pharo developments, maybe
others). But for now we only Morphic and MVC to work with. The good news
is that Morphic and MVC are sufficiently different that they provide a
very good basis for validating the ToolBuilder abstractions.

Dave