Avi Bryant <avi at beta4.com> wrote:
> 
> On Fri, 18 Oct 2002 goran.hultgren at bluefish.se wrote:
> Right.  Since there's no balloon help yet, let me tell you what the
> options are:
> 
> Refresh - update the list of packages
> Load - load a new package into the image from a .st file
> (the only thing that makes this different from simply filing in the
> .st file is that if you go through load the correct file path
> automatically gets associated with the package)
> Edit - change the filepath for a package
> FileOut - dump the current version of the package to disk
> FileIn - update the image from disk
> Browse - open a browser on the PackageInfo class

How do I see the differences between the image version and the file
version (which I understood is the whole point)?
 
> > Of course DVS and SqueakMap could surely be tied together in interesting
> > ways... For example - DVS could subclass SMInstaller (mimicking
> > SMDefaultInstaller) and thus take care of installation/upgrades of
> > packages that have been filed out using DVS. Just one simple problem -
> > currently the installers detect if they can handle the download filename
> > and the default installer gets triggered for .cs.gz, .cs, .st and
> > .st.gz. Another extension perhaps for DVS fileouts?
> Yes, that would be a good plan.  I suppose we could use another extension
> - maybe just something like .dvs.st (since DVS fileOuts can be filed in
> normally if you don't have DVS installed)?
I like the integration idea, don't so much like the naming idea - my
file outs already look like SM-Loader.1.cs.gz - enough suffixes already.
But if we don't find something better, it's better working than not...
 
> > > 4. The PackagePanel seems to get it's list from the PackageInfo
> > > subclasses. Shouldn't it actually use all instances, for packages that
> > > don't define a custom subclass?
> 
> Right now it assumes you have a custom subclass for every package - it
> just didn't seem like that big a deal to have to add a class for each
> package - it doesn't take any longer than creating an instance, it's
> easier to manage (just use the browser), and so on.  
True.

> Does this seem to
> onerous (or too much of a kludge)?
Yes :-) for a one class package, definitely. Not intolerable, probably,
but I'd prefer some lightweight route. Actually, I think it's important
that there be very near zero overhead from working with packages - that
keeps the smallest practical package really small.

How about this -
A registry of regular PackageInfos, that registers the package when it's
first identified (PackageInfo named: 'SM-Loader' would register it) or
loaded (means saving it in the fileout as a do-it). This registry + the
subclasses is the list of packages.

Daniel Vainsencher