What’s in a Smalltalk Browser anyway? Part 2

It’s time for a little experiment: when you start your Smalltalk work the next time, work for, say, 2 hours and stop somewhere in the middle of the process. Look at your opne Browsers: in how many of the did you use the navigate to a Class part for more than just navigating to the class you are working on in that Browser. Sometimes you may have had a look at a superclass, but most of the time the navigation part of the browser takes away screen real estate without being of any use.

Let’s imagine we strip the navigate to the class component out of the browser and put it in a separate window. Let’s also assume that this seperate navigator component can be switched to the way of navigation we need right now: Hierarchy, Application Structure, Categories, Search results etc..

Each Browser then would simply be the remaining three parts: Navigation within the class, editing Class Source and Navigate somewhere else.

There are several benefits I see for an individuel Browser:

  • Uniformity: each and every Browser would be completely identical and concentrate on a single class – the only differences would probably lie in specific editing extensions based on the clas’ type, like a visual editor tab, a unit test runner tab, a code critic tab or a Public Interface editor
  • Context switching is easier. You don’t have to look at the Browser and think about what kind of Browser it is. It’s just a Class Browser.
  • Saved Real estate: Imagine each of your 23 open Browsers uses only 80 percent of the currently used real estate. Well, in case of 23 open browsers the gain is quite limited, but still…

But we’re not there yet.

Let’s also assume that the central navigation window can be linked to the Browsers, and changes its view and functionality depending on which Browser is currently active.

Let’s construct a little example:

Say you used a hierarchical navigation to open the Class Customer and you navigated to the Class Invoice by following the Package Structure and opened a Browser by looking for implementors of #printOn.

If you are currently working on one of the implementors of #printOn: and click on the Browser for Class Customer, the navigation Window will switch to the Hierarchy View and select the Class Customer. If you then Activate  the Invoice Class Browser it will display the loaded Applications and select the Controller of Invoice.

The navigation window should also have some kind of history, so that you can use it to switch to the open Browsers. You could use back/forward buttons on this window to see all the navigations you already performed. When you select one, it would bring the associated Browser on top and activate it. You can choose to navigate anew in order to open a new Browser.

If you are an Eclipse developer, parts of this might remind you of the Package Explorer and Hierarchy View. They can be linked to the current editor in a very similar manner as I described here. It doesn’t have the history feature like I described it, but the rest is quite similar.

Let’s take all of this one step further:

If we now have the option of using the classical multi-window environment or switching to a single-window environment like in Eclipse, we’re pretty close to the way most of today’s IDEs work. Of course we need to find ways to integrate Inspectors, the Debugger and Browsers like the Application Manager or Configuration Maps Browser into this whole picture. But don’t you think this is a logical step forward? I definitely do. If you love to work in a multi-Window environment, all that changed was the seperation of Navigation from Browsing. If you chose to work in a single window, then you’d work in a very comfortable environment like Eclipse.

For a newcomer to Smalltalk, this would probably make things a lot easier, because it feels like home.