Hi Stephen --

> Of course, a good package-based browser would be an asset, but it seems like we’re “letting the perfect be the enemy of the good” as we say here. [...]

Hmm... quite the opposite. It would be perfect, if all packages followed the naming pattern of the original days, as you explained. However, we keep the system manageable by making discoverable what actually happened.

Having a tool with "package" in its name that ignores what an actual package means these days for Squeak is confusing at best.

The feature (or perspective) you are looking for is maybe like "show me all packages that follow the original naming pattern because I think those are the basics a new user wants to browse". And looking at "Chronology-Core", for example, this is not quite right.

I am sorry that we seem to disagree on this one.

System categories (or class categories) can have any granularity:
Games-Tetris-Kernel
Games-Sokoban-Support

Would you want to browse "Games"? Or "Games-Tetris"? It's not that simple. And it is really not about “letting the perfect be the enemy of the good” but about a clear representation of "what is there".

Best,
Marcel

Am 23.01.2023 20:53:01 schrieb Stephen Travis Pope <stephen at heaveneverywhere.com>:

The core of the Smalltalk class library (Magnitudes, Collections, Streams, etc.) are all organized according to category names that include $-, and making the top-level list in the browser small enough that it’s easy to navigate the entire system (e.g., jump to class FileDirectory while editing a method somewhere else that needs file I/O) seems important to both new and experienced users.

Of course, a good package-based browser would be an asset, but it seems like we’re “letting the perfect be the enemy of the good” as we say here.  Take a look at VisualWorks, where they have both category-based and package-based (and namespace-based) browsers.

The same applies to the efforts to simplify/hierarchicalize the world menu.

I’m happy to maintain my changes alone, but the Squeak community really does have to address the bloat, complexity and poor navigability of the current system, and a system reorg, category-based 6-paned browser and compacter menus are all parts of this effort.

stp

--------

Stephen Travis Pope    Ojai, California, USA
    pastedGraphic.tiff<cid:55B397C7-3D20-4E60-A051-4564245235A7 at sd.cox.net>
     http://HeavenEverywhere.com
     http://FASTLabInc.com
     https://vimeo.com/user19434036/videos
     http://heaveneverywhere.com/Reflections



On Jan 23, 2023, at 4:53 AM, Taeumel, Marcel via Squeak-dev <squeak-dev at lists.squeakfoundation.org> wrote:

Hi all --

Monticello came after PARC, I think, and so did the notion of MCPackage and PackageInfo.

I think that it is good practice to not have hyphens ("-") in a package name (both Monticello's MCPackage and PackageInfo) to simplify the explanation of what a package is, namely the stuff up to the first hyphen. But we cannot enforce that in general.

As usual, there is compromise because packages with a hyphen in their name started to appear such as "Chronology-Core" and "Chronology-Tests". So the good-old package-pane browser had to adapt to still offer a consistent perspective on the system.

The entire idea of dependencies is based on MCPackage/PackageInfo. We should not confuse users with the illusion of simplicity when there is none. Instead, keep it honest and discoverable. Avoid "mixed messages".

-1 on this proposed "fix" as it ignores the fact that the very definition of "package" has changed over time

Best,
Marcel

Am 20.01.2023 21:25:57 schrieb Stephen Travis Pope <stephen at heaveneverywhere.com>:

Hello group,

Back in the PARC days, the "package pane browser" was originally called the 6-pane browser, since it had 6 panes.
The top-level was sometimes called meta-categories, but then the name packages came into use.
The list was pretty standard: Magnitudes, Collections, Streams, etc.
These don’t correspond to “packages” in the normal sense.
The idea was to make it easier to find things (if you can’t find it, you can’t reuse it).
I’m fine with calling it the category-prefix browser or something, as long as it’s not broken by changing how the top-level list is generated.

stp

--------

Stephen Travis Pope    Ojai, California, USA
    pastedGraphic.tiff<cid:55B397C7-3D20-4E60-A051-4564245235A7 at sd.cox.net>
     http://HeavenEverywhere.com
     http://FASTLabInc.com
     https://vimeo.com/user19434036/videos
     http://heaveneverywhere.com/Reflections



On Jan 20, 2023, at 8:26 AM, Jakob Reschke <jakres+squeak at gmail.com> wrote:

Hi everyone,

Then we need a discussion what the package pane browser _should_ be.

Since it has "package" in the name, in my opinion it should display packages, not category prefixes. Only then it can meaningfully work with extension methods and truthfully support looking into the package decomposition.

So I still support that patch of Christoph's, even if that is not the original behavior.

Please add your thoughts.

Kind regards,
Jakob



Stephen Travis Pope <stephen at heaveneverywhere.com<mailto:stephen at heaveneverywhere.com>> schrieb am Di., 17. Jan. 2023, 22:27:

Hi team,

There seems to be some confusion about what the PackagePaneBrowser is; the left-most (top-level) list is supposed to be the class category categories (i.e., class category names split after $-, [Kernel, Collections, Graphics, ...], analogous to packages).

CT submitted a recent change that broke this, instead delegating to a PackageOrganizer; this is different and should be in a separate tool.

Here’s a fix.


stp

--------

Stephen Travis Pope    Ojai, California, USA


     http://HeavenEverywhere.com<http://heaveneverywhere.com/>
     http://FASTLabInc.com<http://fastlabinc.com/>
     https://vimeo.com/user19434036/videos
     http://heaveneverywhere.com/Reflections








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20230124/49b399c2/attachment.html>