[UI] ToolBuilder

[Bill Schwab]

Colin,

You and perhaps others (too lazy to search the archives to give proper
credit - sorry<g>) are providing excellent overviews of the various
frameworks.  I would encourage you to slap it on a wiki if that has not
already been done.

If we were going to pick one of them to build a themed version of the
IDE, which would you pick?

It might be a bad idea, but I wondering whether there is enough tool
building in the image now that we could create a custom builder and end
up with the themed IDE "for free".  If that is the case, one might be
able to concentrate on feel in and among Gary's widgets only, and make
that themed vs. maintaining fixes to Morphic as it changes.  It is
possible (likely?) that while I am muttering about the grand fix, Gary
is putting the finishing touches on enough changes in enough of morphic
to make it unnecessary.  There still might be an advantage to limiting
ourselves to theming the feel in a small subset of morphic of interest
to us.  New GUIs would be built in terms of it, and if we can generate
an IDE, then Gary would be able to forget about "the rest of morphic"
except as it affects the subset.

I need to find a small but not trivial project to log some time in the
IDE with Gary's changes.  

Bill




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bschwab at anest.ufl.edu
Tel: (352) 846-1285
FAX: (352) 392-7029

>>> cputney at wiresong.ca 09/08/07 12:53 AM >>>

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


_______________________________________________
UI mailing list
UI at lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/ui