On 11/20/11, David T. Lewis <lewis at mail.msen.com> wrote:
> 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 like option 4 as well.



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

My thanks as well. This is great news that you worked with Lukas to
create a common code base and are working on adaptions to Squeak and
Pharo.

--Hannes


> Dave
>
>
>