Introduction

Additional functionality provided by the new SystemBrowser includes:

• Multiple buffers, change and visited history
  these avoid the "many open views" confusion, and help to keep track of browsed code

• Undo support
  both the editor and the browser itself support very sophisticated multi-level undo and redo.

• Multi-select in all lists
  to apply menu functions on a set of items.

• View classes by category (as done in the old browser), by namespace, by project or by inheritance.

• More powerful search functions ("senders of any", "search for variables", "code search" etc.)
  in addition, all searches can be limited in scope to the current project, namespace, category, hierarchy etc.

• Integrated functionality from the Refactoring Browser and SmallLint tools.
  (code search, rewriting, checking and undo history)

• Additional convenient code generation functionality.
  (accessors, change & update, visitor pattern)

• Drag & Drop for category, class and package change
  also to copy code to other classes (press CTRL)

• Improved dialogs with entry completion
  most dialogs provide very reasonable defaults, for DWIM ("do what I mean") behavior.
  Try changing a method's category and look at the dialog's default ;-)

• Lots of informative feedback
  this includes immediate highlight of variable-accessing methods, instant syntax coloring, quick information about the selected class/method in an info area, additional icons in the lists etc. Select a variable in the inst-var list and see immediately where it is read or written. Also, modified classes & methods are highlighted with a different colour in the browser lists.

• Code completion on Tab-key, or "as you type"

• Completely re-writtten, using the GUI painter.
  this allows for easier extension (for example to add additional menu items)

• Pseudo class categories (such as "changed") and pseudo method categories (such as "redefined").

• Embedded Menu, Canvas and Image editors for resource methods.

• The new code view shows line numbers, highlights variables and provides the CTRL-click menus for implementors and senders. It also supports statement level break- and trace points and lint checks.

• Coverage analysis display. Classes or individual methods can be recompiled with instrumentation and code is shown in different colors in the browser depending on whether it has been executed or not.

• Embedded sunit test runner and indicator of the last result in the method list.

As the NewSystemBrowser is still being enhanced, and new features are added, the following pictures may be outdated and/or the menu description be incomplete.

When started, the new System Browser displays 6 major subviews and two toggle/filter panes; these are:

The actual appearance of the browser depends on the viewStyle setting.
The picture above was taken from an early version with the "Motif"-style in effect. Newer versions of the browser will look slightly different and provide additional (menu) functions.

1. Organization List (category / namespace / package)
2. Class List (flat or hierarchical)
3. Variable List
4. Class/Instance Toggle
5. Method Category (aka Protocol-) List
6. Method (aka selector-) List
7. Namespace Filter
8. Code View

This default appearance is similar to the old browser's appearance; however, the popup menus as available in the various list views are duplicated in the browser's main menu panel.

Organization

You can change the grouping, by selecting one of the other items in the view-menu.

A useful grouping is the Project view:

This enables you to organize your own projects into different packages.

For examples on typical uses of the browser, see the last section(s) of this document.

Class vs. Instance

To switch, there are two toggle buttons named "class" and "instance". Selecting "instance" (which is the default) makes your changes affect the class, and therefore the set of messages which are understood by instances; selecting "class" lets you change the metaclass, and therefore the set of messages which are understood by the class (typically instance creation and initialization messages).

If you are not too familiar with this concept, and you have a Java or C# background, think of the class protocol roughly as "static functions" of the class. However, in contrast to Java, the normal inheritance- and redefinition rules apply in Smalltalk. In other words: in Smalltalk, it is possible and quite common to make use of inherited class protocol or tp redefine it in a subclass.

Toolbar

• New Buffer
  Adds another buffer (Tab). Initially, a full class view on the current class is provided.

• Hierarchy Toggle
  Toggles between hierarchical and flat mode in the class list.

• Recently Changed Methods
  Quick navigation to the most recently changed methods.

• Recently Visited
  Quick navigation to the most recently visited methods and classes.

• Show Inherited Methods
  Toggles between single-class and full class mode in the selector list.

• Format
  Prettyprint the current method.

• Breakpoint
  Set/Clear Breakpoints on the current method(s).

• Class / Selector search and history
  To navigate to a class name or selector. If the entered word starts with an uppercase character, it searches for matching classes, otherwise for matching selectors.

• Run TestCases
  Executes all selected testcases (if no protocol is selected, all of the selected classes' testcases are executed; if no method is selected, all testcases of the selected protocols are executed).
  No debugger is opened in case of an exception (however, exceptions are remembered and the corresponding method is marked with a fail-icon).

• Debug TestCases
  Like above, but opens a debugger in case of an exception.

• Launch
  to start the selected application

Pseudo Categories / Pseudo Protocols

• * all *
  if selected, all classes are shown in the class list

• * as yet unknown category *
  filter for autoloaded classes, for which the category is not yet known

• * undocumented *
  if selected, classes without a "documentation"-method are shown in the class list

• * unloaded *
  if selected, as-yet-unloaded Autoload-classes are shown in the class list

• * changed *
  if selected, classes which have been modified but not yet commited into the sourcecode repository are shown in the class list

• * all *
  if selected, all methods are shown in the method list

• * super *
  this pseudo protocol contains methods which perform a super send

• * obsolete *
  contains methods which are marked as obsolete

• * long *
  contains long methods (>30 lines). The limit can be changed by evaluating "UserPreferences current at:#numberOfLinesForLongMethod put:NNN".

• * uncommented *
  contains methods which have no comment

• * documentation *
  contains pure documentation methods (no code, but a comment). Select all classes of a package and select this protocol to get to the documentation quickly.

• * redefined *
  contains methods which redefine existing protocol from a superclass.

• * must be redefined *
  contains methods which send "subclassResponsibility". These usually need to be redefined in subclasses.

• * required *
  contains methods which have been marked as "subclassResponsibility" in a superclass, but are not defined in this class. This is somewhat funny, as the codeView shows code which does not really exist: the shown code is a template which can be used as a start to implement these required methods. Such non-existing methods are shown in a red color both in the method-list and in the codeView. You can disable those methods via the "Show Syntetic Methods" toggle in the browser's "View"-"Selector" menu.

• * extension *
  contains methods which are extensions from other packages. These are methods which are not contained in the classes own package, but instead have been added by loading another package. These are also called "extension methods", "class extensions" or simply "extensions".

• * overrides *
  contains only those extensions which have actually overwritten an existing method in the extended class. You should be alerted, if you find those in your project/package, as these may lead to unexpected results, if the semantics of the original method is changed in an incompatible way. This kind of conflict can be resolved by using a selector namespace.

• * shadowed *
  contains overwritten (shadowed) original methods, along with their overwriting extension method.

• * coverage unknown or not instrumented *
  contains methods for which no coverage analysis data is available. For coverage analysis, classes or methods must be instrumented, and a test run (for example, running a unit test) is required. Classes are instrumented for coverage anylysis via the "Class"-"Debug"-"Compile Instrumented" menu item.

  Because source code has to be fetched and analyzed, the generation of pseudo protocol information may take some time - especially for large classes. If you don't like this feature, disable it via the browser's "View"-"Protocol"-"Show Pseudo Protocols" menu item.

Icons and Indicators

General indicators after list items are:

• Number of Items - "(x)" or "(x+y)"
  in a class category or package list, "(x)" shows the number of classes in the category/package. In a class list, "(x+y)" shows the number of instance- and class methods in that class. In a method-protocol list, the number of methods in that protocol is shown.

• Changed Indicator - "ʌ" (delta-character)
  an indication that the corresponding item is or has parts in the current changeSet. This typically means, that a class/method has been modified, but not yet been checked into the source code repository. In addition to the indicator, list items are also presented in bold and a redish color (see below).
  The indicator is no longer shown, when the source code repository is in sync with the in-memory version (i.e. after a checkin).

• Extension Indicator - "+"
  an indication that the class contains extensions from other packages. For a method, this indicates that the method's package is different from the classes package (i.e. it's either an extension or is a loose method, which has not yet been assigned to any package).

• SmallTeam Modification Indicator - "!"
  an indication that the class or method was modified by someone else in your team. This requires the SmallTeam development support package to be loaded and active.

•  (launchable UI)
  A visual application (i.e. a subclass of ApplicationModel). These can be started directly from within the browser, by double-clicking on the class, or clicking on the launch (rocket) icon.

•  (launchable non-UI)
  A non-GUI program. A non-visual application. The classes' "main"-method can be invoked directly from within the browser, by double-clicking on the class or clicking on the launch (rocket) icon in the toolbar.
  (To be honest: this has only been added for C/Java freaks asking: "where is the main ?".)

•  (container)
  A container class (i.e. a subclass of Collection).
  Abstract collection classes show an "A" in brackets i.e. "[A]".

• [A] (abstract class)
  A class marked as being abstract; i.e. it is not meant to have direct instances, but provides common protocol for its subclasses.

• [U] (utility class)
  A utitity class is one which only provides helper function methods on the class side.

•  (shared pool)
  A shared pool (i.e. a subclass of SharedPool).

•  (widget)
  A widget class (i.e. a subclass of View).

•  (exception)
  An exception class (i.e. a subclass of Exception).

•  (error)
  An error class (i.e. a subclass of Error).

•  (warning)
  A warning class (i.e. a subclass of Warning).

•  (notification)
  A notification class (i.e. a subclass of Notification).

•  (query)
  A query class (i.e. a subclass of Query).

•  (test)
  A testCase which has not been executed yet. Will change to a green thumbs-up or red thumbs-down, when executed.

•  (testOK)
  A testCase - the icon's color (red/green) and form (thumb-up/down) reflects the result of the last test-run.

•  (autoloaded)
  An autoloaded class - the class as present is only a stub class (proxy). The real class is automagically loaded when required (actually: when any message - especially instance creation - is sent to it).
  Notice that autoloading of classes is no longer a recommended mechanism; it was useful in the early times of Smalltalk, when machines had 8Mb of memory. It often leads to hard to find errors, as missing classes or wrong package path settings are detected very late (i.e. at late runtime) and may easily remain undetected during development.
  Therefore, it is recommended to load complete packages instead, which contain meta information on prerequisites and ensure, that all required code gets loaded. (i.e. use "Smalltalk requirePackage:" instead).
  The class can be forced to load immediately, by either double-clicking on its name, or via the "Load"-menu-Item in the "Class" menu.

•  (library)
  A class library-description. This contains the meta information (included classes, extension methods, compilation and linkage information for a class libraries. This can be compiled by stc into a separate dll and later loaded dynamically.

•  (application)
  A GUI application's description. This contains the information for an executable, which can be compiled by stc to an executable and deployed as such.

•  (utility)
  A non-GUI (console) application's description.

•  (redefines inherited)
  The method overwrites a corresponding method in a superclass.

•  (is redefined below)
  The method is redefined in a subclass.

•  (window spec resource)
  The method is a windowSpec method (i.e. defines a GUI) - double click opens a GUI Painter.

•  (menu spec resource)
  The method is a menuSpec method (i.e. defines a Menu) - double click opens a Menu Painter.

•  (bitmap resource)
  The method is a bitmap-image-returning method - double click opens a Bitmap Editor.

•  (private)
  The method is private (can only be called from code within the class) or protected (can only be called from code within the class or subclasses).
•  (obsolete)
  The method is marked as obsolete. It is left in the system for backward compatibility, but may be removed in one of the next releases. Senders should change their code as usually documented in the obsolete method. Lint will find these places and highlight senders in the code.
•  (work in progress)
  The method is marked as being unfinished or needs some work to be done. Useful especially when working in development teams, or to remind oneself that there are still some issues to be cared for.

•   A breakPoint is set on the method.

•   A trace is set on the method.

• darkened green
  marks extensions; the category, class or protocol includes method extensions from other packages.
  In addition, the class is marked with a trailing "[+]"-string. Notice that extensions are packaged and deployed as part of their package, not the package of the method's class.

  If there are unassigned (loose) methods in the class (these are methods that have not yet been assigned to any package), the class, category and methods are marked with a trailing "*"-string.

• darkened red
  marks changes; the category, class or protocol includes methods which have been changed.
  This red coloring will vanish when the class is checked into the source code repository, or the class menus "special - cleanup changeSet" function is invoked.

• underlined methods (with a variable selected)
  marks all readers of the selected variable(s)

• red underlined methods (with a variable selected)
  marks all writers of the selected variable(s)

• - "happy" - a very simple method.

• - "cool" - a simple method.

• - "fine" - some complexity.

• - "still fine" - some more (but still acceptable) complexity.

• - "mhmh questionable" - take a look, the code might need some simplifications.

• - "ouch" - slightly too complex. Try to simplify.

• - "oh" - rather complex. Should be splitted, parts extracted or otherwise simplified.

• - "angry" - very complex. This definitely needs a rewrite.

Double Clicking

Double Clicking on a Class Category

Double Clicking on a NameSpace

Double Clicking on a Project

Double Clicking on a Class

• A double click on an application class, (i.e. subclass of ApplicationModel or a TopView application), starts (opens) the application.
  Actually, any class which returns true from the #isVisualStartable query message can be started this way.
  Of course, this is the same as evaluating "className open" in a workspace.

• A double click on a class which implements a #main method invokes that method (this has been added for all users who asked the standard question: 'where is the main' ;-)

• A double click on an unloaded (i.e. autoloaded) class, forces the class to be loaded into the system.

• A double click on a TestCase (i.e. a subclass of TestCase) opens the SUnit TestRunner on this testcase.

Double Clicking on a Variable

Double Clicking on a Method

Double clicking on a method with a break- or trace-point will remove the break- or trace-point.

Double clicking on any other method will look if the method redefines an inherited method or is redefined by an inherited method, and will add an inheritance browser page if so.

Drag and Drop

You can drag and drop classes to another class category, to another namespace or to another package.

All of the drag-and-drop functions can also be triggered via corresponding popup menu functions ("Move..." items).

Copyright © 2000 eXept Software AG, all rights reserved