[UI] ToolBuilder
Matthew Fulmer
tapplek at gmail.com
Sat Sep 8 18:56:13 UTC 2007
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
More information about the UI
mailing list