What’s in a Smalltalk Browser anyway? Part 4


In part 3 I’ve forgotten to mention one important fact about tabbed internet browsing: the tabs enable the user do have many documents open at any point in time and to easily switch between them. Each tab has its own history and serves as a Browser within a Browser, reusing all the common stuff like the navigation bar, tool bar, side bars and so on.

A Tabbed Browser, therefore, is a multi-document web browser.

That’s what’s probably wrong in VAST. The Tabbed Browsers use tabs to make navigation within a Class easier and make the Browser look much better than before. They are much easier to understand for a Smalltalk newcomer (remember when you had to learn what it means if the instance/class button says “Class” – does clicking it show me the class or instance methods. And remember how complete your irritation was when you found out you can configure this behaviour…???).

But the Tabbed Browsers in VAST are not multiple-Class browsers that allow you to save screen estate while working on many classes.

That’s where my idea of separation of Navigation within the image and the rest of the Browser comes into play. I am, by the way, not sure if this is an original idea of mine. To be honest, I am quite sure I am just thinking based on the way the eclipse developers built code navigation and mixing it up with a few other concepts. But back to the topic.

If we seperate Image Navigation out of the browsers and put all navigation into a navigator window with it’s own history, we can (at least from a conceptual point of view) easily build a Smalltalk Browsing environment that gives us all existing behaviour plus a lot more.

We could have a navigator that is used to find Classes in the Image, by whatever navigation path (hierarchy, application structure, senders/implementors/references, Search for Strings, Bookmarked methods, whatever, it could/should be pluggable) . This navigator could hold its history and be linked to the browsers, meaning:

  • If you go back and forth through the navigator’s history, it will show the navigation path the user took to the class
  • It will also make the Browser that is associated to this navigation come to the front
  • If the associated Browser has been closed in the meantime, this history entry could either be inactive or ask whether the user wants to reopen it
  • If you activate a Browser, the associated navigation entry is selected in the navigator

This scenario allows for seperate environments: Multi Window or Single Window. In Multi-Window mode each browser, inspector etc is its own window, and the navigator would be an always on top window like a palette in, say, Photoshop or Xcode or the like. In Single window mode, we’d have something like an eclipse perspective that includes some fixed area for the navigator and transcript and an area in which we can add tabs for each browser. This would pretty much look like a Java Browsing perspective in Eclipse. The only difference is the concept I am talking about puts a lot more power into the navigation component.

And no, Trailblazer is not what I am talking about. It’s looking strange, it feels strange and it somewhat is strange in the way you navigate in it.

This concept is somewhat inclomplete in that it has no answers to questions like

  • How does the navigate to semewhere else-part of Browsers fit into this picture?
  • How would we integrate Inspectors and Debuggers into such an environment?
  • How would special Browsers like Shadow Browsers and Config Map Browsers fit in?

But still I think we could find answers here. And I think I’d enjoy working with such a tool.

What do others think about such a setting? Does it sound like a desirable Smalltalk environment? Is this something we should introduce to Smalltalk vendors and try to make tham adopt such a model?