[UI] ToolBuilder

[Matthew Fulmer]

On Fri, Sep 07, 2007 at 09:53:57PM -0700, Colin Putney wrote:
> 
> 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.\

You called my bluff. I don't have much experience debugging
Morphic code, but I did spend a few weeks hating the (self
changed: aSymbol) when debugging some browser code in both MVC
and Morphic, so my synopsis of Pluggable*Morphs was not
objective.

Now that I actually look, I don't see more appropriate Morphs
than the Pluggable ones. 

Sorry for the noise.

> >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.

It would definitely be useful. I don't know if ToolBuilder is
the best way to approach the problem. I have heard that Tweak is
flexible enough to allow a view to be a host widget.

I haven't built anything with Tweak, and I have only just started
with ToolBuilder.

> >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.

Hmm. Thanks for the info

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