The preference you speak of is 'Browser shows package pane'.  Notice,
"Shows" (vs. "not shows"), so it's talking about a pane of the same
browser -- a "Package Browser".

The preference just splits off an extra pane based on the first dash
"-"  to delineate 'Package's.  But this causes it to show the user
utterly wrong and confusing information.  For example, from these
packages,

  Help-Squeak-CorePackages
  Help-Squeak-Project
  Help-Squeak-SWiki
  Help-Squeak-TerseGuide

It makes the user think we have a package called "Help" and puts the
four "Squeak-*" above into it, as if there is some sort of object
delineation there, even though there isn't, not even conceptually!!!

So, let's not let this confusion-causing preference of utter nonsense
get in the way of improving the clarity of our IDE objects and their
descriptions in the various menus.  There is no 'full', it should
simply be 'browse package' and, for now, the preference setting will
decide whether the confusing extra pane shows or not.

After that, I would support asking the list about getting rid of that
Pref and "extra pane" browser altogether.


On Fri, May 11, 2018 at 5:04 PM, tim Rowledge <tim at rowledge.org> wrote:
>
>
>> On 11-05-2018, at 12:07 PM, Chris Muller <asqueaker at gmail.com> wrote:
>>
>> Since we're scrutinizing naming consistency, how about renaming
>> "browse full" to "browse package"?
>
> As Bob  pointed out there is actually a preference for that; personally I don't much care for the extra list and so don't set that pref. So far as I can see we use 'browse full' fairly pervasively around the image to mean 'big dog main system browser' so it's probably best to keep that. I agree it's not entirely wonderful as a phrase but it's a real bugger trying to name things well.
>
> The #classHierarchy thing annoys me a bit though - given we already had browseXXXX all over the place, how did we end up with the utterly unconnected #classHierarchy in order to browseClassHierarchy ? Madness I tell you. I did my best to change that neatly in the ObjectExplorer locale but it's there again in all sorts of StringHolder subclasses and I just don't have enough time to track it all down today. Must resist rant about insanity of StringHolder subclasses..........
>
> I dare say somebody will point me to a browser that does this, but it occurs to me that being able to swap the view-point of a currently open browser between system-full-broswer and hierarchical (and maybe others, who knows) might be nice. And maybe the default effect of find-senders/implementors in a hierarchical focussed browser should be the 'local XXX' instead of global - not removing the global, just swapping the ordering of the two options or some similar approach.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful random insult:- Trying out for the javelin retrieval team.
>
>
>