What I really want for SystemNavigation is for it to be a facade for finding
"code-elements" in Squeak, and nothing more.  This could facilitate the
creation of alternate IDE's.   I want to use SystemNavigation to find WHAT I
want to browse and use that as input to the BROWSER I want to display it in. 
For this reason, the tight coupling between SystemNavigation and existing
browsers (the methods in the "browse" category) should be removed from
SystemNavigation and moved to various constructor methods of the various
browsers.

Additionally, I think SystemNavigation should become stateful, so that it can
know a context of code elements.  For example, I might want one
SystemNavigation for MyProject1, another for MyProject2, etc.  Yet another
might be for the remote image that somebody mentioned.

  SystemNavigation for: MyClass  "uses MyClass as the context for all
references, senders, etc."

  SystemNavigation for: { MyClass.  MyOtherClass }

  SystemNavigation for: { MyPackage1.  MyPackage2 }

Double-dispatch could provide us with this uniform, friendly "for:"
constructor.

I have nothing against a "default" one that references everything in the local
image.

Thoughts?

 - Chris

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com