On Fri, 14 Jan 2005 06:08:19 -0500, John Pierce
<john.raymond.pierce at gmail.com> wrote:
 
> The thing about the fourth pane (the method pane) is that it *can* be
> populated when the 2nd pane is selected (the class pane).  It's like
> the third pane (the protocol pane) is just there to act as a filter to
> the fourth pane.  I wonder if thinking about "some panes being
> filters" can open some possible ways to solve the problem generally
> and to remain happy with the design.  I'll think about it more as I'm
> sure you will.

That's a nice thought.  It reminds me of the iTunes
Genre/Artist/Album/Song column browser: if you make no selection in
the first three, you'll see all the songs in the system; if you make
just an Album selection, you'll see all the songs in that album; if
you make just an Artist selection, you'll see all the albums for that
artist and all of the songs on any of them; if you make just a Genre
selection, you'll see all the albums of that genre and all of their
artists (and if you then choose an artist, you'll only see their
albums that are of the right genre).  You probably have to try it to
fully appreciate it, but basically it's treating every column as a
filter, and not making you select them in order (though a selection
will only ever affect columns to its right, never to its left, so it's
still hierarchical in a sense).

There's a neat file manager out there somewhere, whose name I've
unfortunately forgotten, that doesn't have that right->left
restriction - making a selection in any column will constrain all the
others.  That might be more like what we need in Smalltalk (choose a
selector, and the class column narrows to only show classes that
implement it).  But that would also be much harder to retrofit onto
the OmniBrowser model, I think.

Avi