On Fri, 18 Oct 2002 goran.hultgren at bluefish.se wrote:

> danielv at netvision.net.il wrote:
> > A few small things -
> > 1. It seems to open the PackagePanel when it comes up. It has five
> > buttons, and it's not quite clear what they mean, or what exactly is
> > shown in the list below, and how I add/remove things from it.
> >
> > In short, a help menu item/balloon help would be useful.
>
> Balloon help is simple and nice.

Yes, good idea, I'll add some.

> > 3. Looking at the PackagePanel, it also seems to support loading
> > packages. How does it relate/differ from the SqueakMap browser or
> > loader? when does one use it?
>
> Eh, now you are confusing things... "loading" in this respect is (I
> guess) loading from .st files on disk.
> DVS is a CVS mirroring tool just like CVSTProj - but a little bit
> niftier in design I guess (going through ChangeSets).

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

> 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)?

> > 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.  Does this seem to
onerous (or too much of a kludge)?

> Eh, AFAICT PackageInfo is not a "real class" - it's a "hack" so that you
> can include data about the "package" by simply putting such a class in
> your class category.

Well, it is a "real" class, in that the core of DVS is the PackageInfo
class, and so you can override lots of interesting methods in your
subclass.  A very simple example is DVS itself, which overrides
#externalName so that it files out as "DVS.st" instead of "Packages.st".
But you might also find it useful to override #includesClass: or
#isYourClassExtension:, for example.