On Fri, 17 Jun 2005 11:57:38 -0600, "Brian Brown" <rbb at techgame.net>
said:
> 
> On Jun 17, 2005, at 12:45 AM, goran at krampe.se wrote:
> 
> > Great job!
> >
> > I am interested in hearing more about how this integration ideally
> > should be done. Remember - we don't want to just add stuff to the  
> > image
> > - we need to try to think as much as possible in "packages" here.
> 
> This certainly bears discussion :-)
> 
> We have a simple API that abstracts the gui toolkit currently in use  
> (Morphic, Tweak, etc)  from the Tools being rendered (Monticello  
> brower, Omni Browser, Squeak Map).
> 
> So do we make ToolBuilder a package, and have all the core tools  
> check to see if the package is loaded, use it if it exists, and  
> default to Morphic if it doesn't?
> 
> Our change sets already make modifications to those tools, changing  
> them to use ToolBuilder, so then the ToolBuilder maintainer would  
> need to track the core Tools and keep changes up to date as those  
> tools evolve.
> 
> This scenario doesn't seem ideal to me, but I could be missing  
> something. If ToolBuilder (which is quite small) was part of the  
> image, then it becomes the defacto API for dealing with prompts,  
> dialogs, menus, etc.

I should respond since I'm technically the "V3.9" guy.

I don't want to speak for Goran, but I think he was saying that
generally, major new tools should ideally have their own package.

But there's a big difference if the bulk of the code is new code, or if
it's mostly changes to existing code in the base image (or the packages
which make up the base image, if we're "thinking in packages" :-) ).  In
the case of the ToolBuilder code, it sounds like the bulk of the work is
changes to existing code in the image (to remove Morphic dependencies
etc), and the ToolBuilder code itself is relatively small.

Given that, I agree with you that these changes should not be kept
indefinitely in a separate package, they should be applied once
(preferably very soon) to the base image (or the packages which make up
the image).

On a side note, I think we're pretty close to finally package-izing the
base image, using the Impara iSqueak work as a starting point for
3.9alpha.  See the Packages team mailing list at
http://discuss.squeakfoundation.org/cgi-bin/ezmlm-cgi?10 for current
discussion.

So, we should plan on applying these changes early in 3.9alpha if they
are ready to go.

> Of course, if all the core tools are packages that depend on the  
> ToolBuilder package, then the problem goes away...

Yes, that's another question... should the ToolBuilder classes
themselves be in their own ToolBuilder package, or should we just lump
them in with the larger "Tools" package for now?  (Which includes
Browser, Debugger, etc.)  Either is fine with me.  It could always be
split apart later if we group them with Tools for now.

- Doug