On Sun, Nov 20, 2011 at 12:56:26AM -0800, Colin Putney wrote:
> Hi folks,
> 
> Lately I've been working with Lukas Renggli on a new version of
> OmniBrowser. The main focus has been on cleaning up and isolating
> platform dependencies so that we can have a single version that works
> well on both Squeak and Pharo, while fitting comfortably into each
> platform's idioms. That part of it has been quite well.
> 
> For proper integration with Squeak, I've been trying to get OB
> building its interface using ToolBuilder. It *mostly* works, but there
> are some areas where ToolBuilder doesn't provide the functionality
> that OmniBrowser needs. I had planned to extend ToolBuilder a bit with
> the additional functionality that OB needs, but that turns out to be
> more work than I anticipated, and I wasn't able to get it done before
> the 4.3 feature freeze. So, given the constraint of working with the
> Squeak 4.3 feature set, I'm not quite sure how to proceed.
> 
> Here are some of the options:
> 
> 1) Abandon ToolBuilder and just deal with Morphic directly. This is
> what OB has historically done, and I'd just be updating the old
> Morphic code to fit better into modern Squeak conventions. There's no
> longer any need to have this code work on Pharo, since Lukas is now
> using a separate Polymorph-specific widget package on Pharo.
> 
> 2) Use ToolBuilder where possible, but customize its output. This
> misses the point of ToolBuilder, since it means OB won't be able to
> work with MVC, but at least it reduces the chance that OB will get
> left behind if someone adds a feature to ToolBuilder. It is a bit of
> "worst of both worlds" situation.
> 
> 3) Use ToolBuilder, and just accept that not all the features of OB
> will be available until they get added to ToolBuilder. I'm not sure
> how much graceful degradation I can acheive, but it might not be too
> bad, and it'll give us (me) motivation to improve ToolBuilder for
> Squeak 4.4.
> 
> 4) Have the OB installation process patch the base image to add the
> needed functionality. That would be the cleanest in terms of the OB
> code, but has the potential to break other packages that users might
> want to load.

This (option 4) sounds like the right thing to do. Toolbuilder is
not really complete at this point, so it seems likely that whatever
you need to implement for OmniBrowser will turn out to be the right
thing to do in the long run. I am not aware of any other projects
in development that would lead to conflicts, so if you add ToolBuilder
extensions to OB now, adopting these in the base ToolBuilder package
later should be no problem.

> 
> I'd really like to make this next release a solid toolset for Squeak,
> and fix a lot of the little annoyances that cause Squeakers to avoid
> it. Lukas' refactoring stuff is really excellent, better than the
> VisualWorks refactoring browser IMHO, and I want to make it palatable
> to more people in the Squeak community. I'm leaning towards option #1,
> because I suspect it's the mostly likely to achieve that, but I
> thought I'd put it out there and ask the community for advice. So, how
> important is ToolBuilder? What options am I missing?

Thanks for doing this. Improvements to ToolBuilder would be welcome, and
having them driven by the requirements of a real application (OB) should
help ensure that the right features are implemented.

Dave