It's not much "harder" to get to in terms of number of gestures.  You
can select "browse class" and, voila, there are your ClassVars, ready
for printing or inspection.

IMO, we should consider and encourage the idea that interacting with
code in the browsers is as much a part of the IDE as the menus and
buttons.

<soapbox>
This seems like a good opportunity to express my views about what
Squeak is, or at least can be.  It seems like there are two prevailing
ideas in the community; one that Squeak should be like an "app" where
the goal is to insulate the user from ever seeing code or the
debugger, and therefore we need a widget (button or menu) for every
action the user might ever want to do.

The other prevailing idea is that Squeak is devevlopers-tool (like
Eclipse, etc.) and should regard its users as full-on developers.

It seems like every software out there wants to cater to one of those
two groups, but not anyone who is looking for something else.  Squeak
has the chance to be that something else that empowers regular people
who are not programmers, but very intelligent and wanting to use their
computer for useful purposes -- if only they had an empowering
software "application" other than, at one end, some kind of Office
package (usable but not capable) and, at the other, Emacs and a
C-compiler (capable but inaccessible to them).

As another example, hiding the debugger to put up a generic error
message in an alert box totally subverts the strengths and even the
original vision of the Dynabook.  It's supposed to be a personal
computing system, the Debugger is the most useful and empowering
browser in the system.  The Squeak environment should never swallow
its own bugs.

Another example is breakpoints vs. "self halt".    We have all
this.... crazy stuff to support them; swapping out CompiledMethods,
restoring them under certain circumstances, and even creating a new
soft-dependency from Compiler to Tools!  All this, just so the user
can select "breakpoint" from a menu instead typing "self halt" in a
method?  IMO, "sparing" the user from interacting directly with the
code is not helping them in the long run..
</soapbox>


On Wed, Aug 26, 2015 at 6:10 AM, karl ramberg <karlramberg at gmail.com> wrote:
> Hi,
> There is no menu item to inspect or explore the class of the inspected
> instance. Many constants hide in class variables and are harder to get to
> when there are no menu short cuts.
>
> Karl
>
>
>