[UI] ToolBuilder

Matthew Fulmer tapplek at gmail.com
Sat Sep 8 19:08:46 UTC 2007


On Sat, Sep 08, 2007 at 04:09:01PM +0200, Jason Johnson wrote:
> On 9/8/07, Matthew Fulmer <tapplek at gmail.com> wrote:
> >
> > The default squeak browsers use the Pluggable*Morphs, whose sole
> > purpose was to get the toolset, which was and still is written
> > for MVC, to work in Morphic. They are not terribly useful morphs
> > and are not representative of Morphic at all. They are the
> > keepers of most of the "Unspeakable Horrors" in Morphic.
> > Unfortunately, due to the popularity of the toolset, these
> > widgets have given the average squeak developer a bad image of
> > Morphic.
> 
> This may be naive, but from reading the Self papers, my impression of
> what Morphic was supposed to be about was rapidly building GUI's.  For
> example, from reading that paper I would expect to be able to grab a
> "bare window" morph, a big "text area" morph, a menu morph, 4 flap
> morphs (one for each side), each with a tab morph inside and have a
> shell that looks like the InteliJ IDE in about 5 minutes.
> 
> I'm guessing this isn't possible in the Morphic we have, or else there
> wouldn't be 3 or 4 different "builder" tools across 3 or 4 projects.
> We would just build views interactively the way we write model code
> (except visually).
> 
> So my question is:  Why isn't it this way?  Did I just misunderstand
> the point of Morphic?

I think the reason it is not this way is because you can't shove
a visual construction into a Monticello repository. Imho, that
is the only reason.

> > Jason: Could you describe MVP and what it is? I read a tutorial
> > once but didn't get it...
> 
> Bill can correct me if I go wrong, but for me MVP is:
> 
> Model)
> 
> Same as MVC, just normal domain classes with the small extension that
> they can send events when they change state.
> 
> View)
> 
> This is actually like the model except it's domain is user
> interaction.  Unlike MVC views (afaik) MVP views know how to draw
> themselves and how to deal with user interaction.  They can send
> composite events, for example if you click a value in a list, hold
> down select and click 5 lower, the View can generate a "multiple
> values selected" event.  You can also do things like PDA style
> gestures and so on.
> 
> Presenter)
> 
> This is like the descriptions in Magritte.  You basically define a
> view independent presentation of a model.  For example, a simple
> string in Dolphin would probably have a StringPresenter for it
> (MAStringDescription in Magritte I believe).  The presenter does not
> specify things like where the string should be drawn, but it does do
> some of the extra wiring between the Model and the View.
> 
> A model can have zero or more presenters, a presenter can have zero or
> more views.

If I understand you, this is exactly the model used by Pier: all
models are described using Magritte. A few custom views exist
for using the Magritte description in non-standard ways (like
building wiki syntax from the Magritte model).
all the real rendering work is done
by Magritte. 

I really liked the way Pier works ever since reading about it; I
guess now I have a name for it: MVP + CSS. I will have to try
building something with it sometime to get a feel for it, but it
sounds like it could be pretty general-purpose.

-- 
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808


More information about the UI mailing list