On 8 févr. 05, at 1:39, Doug Way wrote:

>
> On Mon, 7 Feb 2005 11:37:48 +0200 , goran.krampe at bluefish.se said:
>> (some stuff snipped here and there)
>>
>>> Although it would be nice to be able to unload packages that are 
>>> there.
>>>   But you can unload Monticello packages (and any other package type
>>> based on PackageInfo), which I guess you already know.
>>
>> Yup, I know. :) And hey, I will add it to the SqueakMap Package 
>> Loader.
>> I just haven't since it felt like a "teaser" that will only awaken the
>> deamons. ;)
>
> Yeah, it would be nice to have in the Package Loader.

We should have the necessary infrastructure and then see if we can 
reduce it.
>
>> Sorry, I meant PackageOrganizer. And note it has a class instvar 
>> called
>> #default.
>> And btw, I now installed version 18 of PI into 3.9a-6550 and that 
>> silly
>> halt bugs me. Can we get rid of that somehow?
>>
>>> package on SqueakMap.  Is this just the list of packages which shows 
>>> up
>>> when you open the "Package List" window?
>>
>> No, that list is... well, is is quite slimmed down. :)
>
> For what it's worth, that list seems to correspond to "PackageOrganizer
> default" whenever I happen to look at it...

We should remove that packageList widget
because we can't do anything with it.


>
>> Personally I think it is a bit confusing - we have 3 things currently
>> making users confused:
>>
>> 1. Package browser. The old browser that packagifies class categories.
>> IMHO it should be called something else.
>
> Yes, we need to rename it ASAP.  Just call it something like
> CategoryBrowser and be done with it.  It may soon become somewhat
> irrelevant if Packages become the principal organization of classes,
> rather than Class Categories.

And also deprecate it.

>> 2. The above mentioned Package list. It feels a bit... well, can't we
>> integrate this stuff in the SM Loader?
>> 3. SqueakMap Package Loader which perhaps should be renamed to 
>> "Package
>> Manager". That way it implies more than just "loading". I mean, it 
>> does
>> also show what packages are installed etc.

Loader is good.

>> So either we make something more out of the "package list" or we zap 
>> it
>> and improve the SqueakMap Package Loader to become the One And True
>> Place For Packages. Which is my suggestion. :) It should for example 
>> be
>> easier to see what packages are installed - currently you need to 
>> apply
>> a filter - and newbies might not even find the damn menu. ;) Perhaps a
>> button row somewhere in this tool would make it more newbie-friendly.
>
> Well, this issue needs some more thought.  The Package Loader currently
> also treats changesets, .sar files etc as "packages".  But they're not
> "real" PackageInfo packages.  I'd like a list or browser tool somewhere
> which only shows the "real" packages, which can be browsed, unloaded,
> and otherwise manipulated.
>
> I suppose one solution is to have the Package Loader show the installed
> items, including real packages and other SMpackages (changesets, etc).
> But only have the Unload/Browse/etc capability enabled for the real
> packages, which you suggested below.
>
> I guess I mainly just want to see the list of all real packages when
> browsing source code in the image.  So perhaps all we need is a real
> Package Browser (sort of a different System Browser) which lists 
> Package
> names in the upper left corner, and then the next four panes across the
> top are the same as the MC Snapshot Browser, including Extensions etc,
> and then a code pane at the bottom.  You use this tool to browse/edit
> all the code in the image (but it could also do a few extra things like
> unload packages, too).  Then we wouldn't need the Package List.  And
> this is somewhat separate from the Package Loader/Manager's
> functionality.
>
> Actually, you still need to keep the System Browser, though, or
> something like it.  One browser needs to have the package-centric view,
> with extensions grouped with the package.  And the other browser needs
> to have the class-centric view, with extensions grouped with the class.
> (This is exactly what ENVY had.)

Alex is working on that.
>>>

>>> Basically, the Package concept needs to be more available in the UI.

Yes Alex is working on that.

>> Mmmm. Again, I wonder if "Package List" really is worth having around.
>> :) What are the compelling reasons?
>
> Okay, maybe get rid of it if we have both a Package Manager/Loader and
> Package Browser.

Yes kill it

>> Great. Let's do it. We simply just add a cs that makes PIs more or 
>> less
>> based on the current class categories IMHO. Stuff can be moved around
>> later. Agree?
>
> Ok, although it may be worth pausing *briefly* to consider Stephane's
> comments about whether we should use a real object instead of
> PackageInfo with its string-based naming hack, so that you can e.g.
> easily rename a package without worrying about the class category 
> names.
>
> Maybe there is a simple solution using a real object which has a 
> similar
> API to PackageInfo and organizes packages in exactly the same way, 
> which
> is also reasonably backward-compatible with existing browsers.  But I
> don't want to wait long either, we need to look at it now and make a
> decision.

Yes alex started to have such an approach that is
	backward compatible
	does not change MC.

> I think we are agreed that we do not want to tackle namespaces or
> anything like that right now, at least.

Oh yes. Please do not put the mess.

>
> Right, well, I'm just talking about the very basics, I think we already
> have most of what I would consider a basic plan:
>
> - We will use the update stream to partition and then detangle the
> image.
> - We'll assign maintainers to each package after partitioning, before
> detangling.
> - We will use XXX (PackageInfo or something very similar) as the basis
> for packaging. (This one isn't decided yet.)
> - etc.
>
>> (snip)
>> I am all with that.
>>
>>> Basically, I don't think we can really consider getting rid of the
>>> update stream until #6 (full dependencies) is done.  And even then we
>>> may keep it.  Or not, who knows? ;)
>>
>> Sure. Let's stick to it.
>
> Great.
>
>>> My other thought is that we should make the initial partitioning as
>>> coarse as possible.  "Graphics" is one package, "Morphic" another,
>>> "Kernel", "Tools", etc.  This will make it easier to detangle, if
>>> you're only worrying about large pieces... don't worry about breaking
>>> the large pieces into smaller ones until later.  At this point, no 
>>> one
>>
>> Exactly my view. It doesn't matter if they "overlap" in wrong ways in
>> the beginning, just as long as every line of code belongs to 
>> *someone*.
>> Then the people in charge can work it out between themselves.
>
> Great.  Getting back to finding maintainers, it might be best to assign
> four or five maintainers to a big package like Morphic (with one lead
> maintainer), rather than assigning individual people to smaller pieces
> like Morphic-Windows, etc.  We will probably have more success getting
> complete coverage that way.
>
>>> (Then there's the whole issue that PackageInfo is based on the 
>>> strings
>>> of the class categories and method categories to define the code that
>>> it contains, which is kind of a hack, but it works and is compatible
>>> with existing tools.  It wouldn't be hard to convert 
>>> PackageInfo-based
>>> packages to a more "real" modules system later, after the detangling 
>>> is
>>> done... it's the detangling that's the hard part.  I'm not sure we 
>>> want
>>> to wait around for a more proper modules system before we begin
>>> partitioning & detangling.  I guess one problem with this is that you
>>
>> No, we should definitely not wait anymore. I am not even sure what we
>> would be waiting for.
>
> Well, let's hear what the other alternative is, anyway.  (For a *Brief*
> moment. :) )  But it is true that we could convert PackageInfo packages
> to something more robust later, since the eventual package
> partitioning/detangling should be roughly the same whichever one we 
> use.
>
>>> may end up changing the class categories of a lot of classes to make
>>> this work.  For example, "Collections-*" might have to be renamed to
>>> "Kernel-Collections-*" if we want the Collections-* classes to be in
>>> the Kernel package, which is where most of them would need to be.  
>>> Can
>>> the package names be unrelated to the class category names?)
>>
>> Well, I would favour having separate packages. Why can't collections 
>> be
>> a separate package?
>>
>> I mean, sure - it will never be uninstallable, but it seems you would 
>> be
>> able to upgrade it to newer releases at least. Hey, that is a thought
>> worth noting...
>
> My initial thought was that the single Kernel "package"/image could run
> on its own.  But I don't have a strong opinion on that.  We can let the
> people in charge of those areas decide.
>
>>> (And I know the above is only 80% thought through, but announcing a
>>> plan and starting on it is a sure way to get feedback!)
>>>
>>> - Doug
>>
>> Let's just roll with it - the plan is fine. I say we just MOVE FORWARD
>> and people can yell if there is anything. :)
>
> Alrighty, we're getting ready to roll. :)
>
> - Doug
>