On Mon, 9 Jul 2001 01:18:28 -0700, "Jim Benson" <jb at speed.net> wrote:

> As I see it, the current browsers do a smashing job of classifying the
> system into named categories. What it doesn't do is tell me how the various
> classes interrelate. While I hate to use the term 'CASE tool' , it's
> difficult at a glance to tell what the design intentions behind a small app
> are (or even what the apps are ;-) and how the classes are related. Even
> simple apps require that you have more 'image' specific knowledge than is
> reasonable to expect.

I generally speaking open a class hierarchy browser on each class I am
working on when I'm doing development. I also move all the class categories
for my classes up to the top of the list, so if I do use a category browser
they are there when I open one.

The other thing I do is change the real estate policy to open windows in a
cascade fashion, from somewhere near the top left corner. I can't work when
I've got browsers all over the screen. I open the browsers when I start a
project, and unless I do some serious refactoring they stay that way.

Having the classes in the category browser be in alphabetical order is a
waste of screen real-estate in my opinion. The fact that SmallInteger shows
up under Random because the letter R comes before S is worthless to me when
I'm trying to understand how the classes are related. Showing the classes
in hierarchical order, with indent, tells me something about how the
classes in that category are related...

When I was at The Object People back in the early nineties, Anthony Lander
and I wrote a category browser in Visual Smalltalk that worked somewhat
like the ST-80 category browser, except all the lists were multiple select
(and all the operations that made sense worked on multiple selections), and
the classes in the class list show up in hierarchical order, with indent.

If you selected three class categories, all the classes in those categories
showed up in the class list, in hierarchical order. In the same manner, if
you selected three method categories, all the methods in those three
categories showed up. We did the state of the browser as an object, and we
had a stack so that you could push and pop the browser state if you wanted
to go down a side path, without opening another browser. The browser state
even kept the contents of the code pane, and its dirty flag, so in the
middle of editing a method, you could press Alt-C to push the state (which
automatically cleared the dirty flag after the state was saved), move over
to a different class to find the name of the method you were looking for,
and then press Alt-V to pop back exactly where you were. The browser also
did auto-completion with combo boxes in all the prompter dialogs, with
remembered history. We also added a file-out framework, so we could, in any
of the four list views, grab a selection of entries, and file out whatever
we selected in pretty much any fileout format, including ST-80, IBM
Smalltalk, HTML, etc...

We also had change sets integrated in the browser. When you selected a
"current" changeset for the browser (from a drop-down combo box above the
class categories), any method or class (plus the categories they were in)
showed up in the list views in blue, with normal items in black.

Oh yeah, and it was *fast*... Really, really fast...

Later,
Jon

--------------------------------------------------------------
   Jon Hylands      Jon at huv.com      http://www.huv.com/jon

  Project: Micro Seeker (Micro Autonomous Underwater Vehicle)
           http://www.huv.com