Monticello should have some UI extension hooks

Daniel Vainsencher danielv at netvision.net.il
Mon Jul 28 20:21:57 UTC 2003


[registry should be in PI, MC and other UIs should only display it]
Ok, I agree. I might add one to MudPie, when I get the visualization 
back, for example.

About MC and alternative package definitions - yes, I've been having a
little trouble when I make extensions/fixes to squeak in relation to my
packages (Garden, specifically). To make the package simply work, I
should categorize the method added as *garden. However, in this specific
case, the right thing is to add these methods to the image. To send them
into the list, they should be categorized something more ordinary.

IOW, we need some sort of "patch" concept. This would hold stuff that
specifically *doesn't* belong in this package, but is being included as
a patch to one of the packages prerequisites. I am entirely unsure as to
what exactly MC should do with these things...

For example, if I add an accessor, but the design solution that gets
implemented in the image is different, then the conflict, the fact my
patch is no longer relevant, will be hard to detect. Very annoying...

Daniel

Avi Bryant <avi at beta4.com> wrote:
> 
> On Mon, 28 Jul 2003, Daniel Vainsencher wrote:
> 
> > I think Monticello could be a good base on which to hang various package
> > level code management functions. Currently, since the browser don't
> > recognize packages, there's nowhere to put them.
> >
> > I'm talking about things like the "recover related code from that
> > changeset" feature I sent it back then, but also about external stuff
> > like "use MudPie to visualize this package". I'm sure you have your own
> > tools that are just begging to have something like that.
> 
> Really, it's that PackageInfo should have these hooks, and any UI that
> deals with packages (of which Monticello is the main current example)
> should honor them.
> 
> Although your recovery code did get committed into the Monticello package
> recently, it really belongs in PackageInfo-Extras.  If we had a
> PackageInfo based UI registry, that would be more feasible to do.
> 
> I should also point out that although Monticello currently is used with a
> 1-1 relation between an MCPackage instance and a PackageInfo instance,
> this doesn't need to always be the case - you could version any other
> notion of package that you could build suitable definitions for.



More information about the Squeak-dev mailing list