[UI] ToolBuilder

[Colin Putney]

On Sep 7, 2007, at 3:30 PM, Matthew Fulmer 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.

Interesting. What would the "proper" way of doing this in Morphic  
look like? In OmniBrowser I initially used the same Pluggable*Morphs  
as the existing toolset, but eventually had to create custom versions  
of them to override behavior of the old toolset that was hard-coded  
into the morphs. On the other hand, I don't use any of the  
pluggability features, since OmniBrowser (almost) always has exactly  
one model per view. If there were a cleaner/better way of doing this,  
I'd love to use it in OB.\

> ToolBuilder has an equally utilitarian original purpose: port
> the toolset to Tweak. Thus, it currently supports exactly what
> is needed to implement the Toolset. Unlike the Pluggable morphs,
> it creates a new, incompatible but slightly simpler abstraction
> layer, meaning that the entire toolset must be ported to use it.
> PlusTools is the name of this port, and it is not in the image
> by default.

In practice, ToolsPlus was about porting the toolset to Tweak, but in  
theory it was about making GUI-independent tools. I think that's a  
worthy goal.

> OmniBrowser is another abstraction created for the toolset. It
> is mostly a new model rather than a new view. That said, it does
> have it's own view abstraction I know nothing about.

OmniBrowser is about structuring the model in such a way that it can  
be presented via the GUI in a standard way. That frees tools  
developers from the details of drawing and events so that they can  
focus on the semantics and functionality of the tool. It's a trade- 
off - less flexibility for more reuse. It has a view abstraction  
similar to, but simpler than, ToolBuilder to allow it to work with  
different GUIs. There are four so far - local Morphic, remote  
Morphic, the web and a fake UI used for testing.

> Monticello uses yet another custom view abstraction, or so I
> have heard. I know nothing about it.

MC doesn't have a formal view abstraction per se, it's just that it  
has quite a few tools that are structured similarly. It's  
aggressively factored to minimize duplication, which leads to an  
abstraction of sorts.

> Also, I don't know if ToolBuilder supports dynamic UI's; all of
> squeak's tools are build-then-forget; the UI is never changed
> once built. I don't know if that is a technical limitation or a
> lack of imagination.

I looked into this, since OB relies on creating rebuilding views  
dynamically. It seems to be possible, but not the "usual" usage pattern.

> Jason: Could you describe MVP and what it is? I read a tutorial
> once but didn't get it...

Colin