> Yes, that's the way it seems to be done.
> 
> There are a couple of design patterns in Morphic that work differently. There
> are the Pluggable*Morph classes that actually get changed notifications and
> go out to a model for the info they need to display themselves.
> 
> Then there are a number of Morphic classes that hold on to their own model
> (or _are_ their own model), and ask that model for its current state
> during their step or draw methods.
> 
> --
> Ned Konz

Big problem with MVC is that it's so seperated, that you need lots of
glue code, lots of adaptors to make the domain model talk to the
widgets.

Now with morphic, alot of it is taken care of for your. Morphic widgets
come with enough internal 'brains/state' to avoid having to write alot
of adaptors and glue logic. First, all widgets have a unifying basic
protocol, so it's easy to make morphs talk to each other.

Secondly, they come with some very nice interfaces to make it easy for
them to talk to your domain model.

Remember, that even inside the MVC paradigm, the Views/widgets also have
MVC inside them. Problem was that all the V aspect provided was bare
bones, You had to write the MC parts yourself ( all those darn adaptors,
basically models for the widgets, and even mouse handling controller
stuff ).

Morphic wraps up the MVC stuff on the View side quite nicely, and it's
quite flexible.

Though the heirarchy could be cleaned up ( and it is ), and some things
could be ironed, it's the best UI system I've ever seen. 

Why should I have to write a listener for every fricking UI object in
JAVA? Why can't I just tell the damn widget what to listen to? In
morphic, you can... ;)

Daniel