Discovering and managing GTSpotter extensions

GTSpotter is moldable. The default Pharo 5.0 image comes out-of-the-box with 122 distinct types of search processors. Understanding and controlling these processors is key for using Spotter to its full extent.

The first thing about it is to learn what these extensions mean. Each of these extensions is defined in a method, and the average size of such a method is 8.5 lines of code (including the header and the annotation line). In most cases, the code of the method is the best description of what they do.

Let’s take an example:

TClass>>spotterMethodsFor: aStep
    <spotterOrder: 10>
    aStep listProcessor
            title: 'Instance methods';
            allCandidates: [ self methods ];
            itemName: [ :method | method selector ];
            filter: GTFilterSubstring

As this method is defined in TClass, the search processor will get activated when Spotter will get to a class object. In this case, there will appear a search category that:

• will be entitled 'Instance methods’
• will be applied to self methods
• will use the method selector as textual description for the item, and
• will filter using a GTFilterSubstring strategy.

Most Spotter extensions look like this. Once you know how to read one, you will understand most of the others.

While each search processor can be small and easy to understand in isolation, understanding the overall landscape of all extensions is another problem on its own. To make it easier to grasp what exists, there are several places to look at.

First, the Spotter help lists all extensions available in the image split by name of the corresponding classes. This is a useful entry point to get a quick overview.

However, if you look for live examples you can simply inspect GTSpotter, and you will get the list of all extensions.

These two tools can allow you to keep track of extensions. Keep in mind that the default start object when opening Spotter is an instance of GTSpotter. Thus, to look only for the top level extensions, we can inspect this expression:

GTSpotter spotterExtendingMethods select: [ :each | each methodClass = GTSpotter ]

In the Moose image, this returns 25 extensions. But, what if you do not want all these extensions?

For this you can turn to the Settings Browser. Every extension in the image gets associated dynamically a setting element. Unchecking the setting will disable the corresponding extension. These settings can also be stored and loaded for use in further images like any other settings.

This mechanism can also be useful if you want to change the way a search works. For example, the top search for classes happens based on a substring filter strategy:

GTSpotter>>spotterForClassesFor: aStep
    <spotterOrder: 10>
    aStep listProcessor
            allCandidates: [ Smalltalk allClassesAndTraits ];
            title: 'Classes';
            filter: GTFilterSubstring;
            itemIcon: #systemIcon;
            keyBinding: $b meta;
            wantsToDisplayOnEmptyQuery: false

If you want to use a regular expression instead, you disable the default class search in the Settings Browser, and add another extension method in your own package with a regular expression filter:

GTSpotter>>mySpotterForClassesFor: aStep
    <spotterOrder: 10>
    aStep listProcessor
            allCandidates: [ Smalltalk allClassesAndTraits ];
            title: 'Classes';
            filter: GTFilterRegex;
            itemIcon: #systemIcon;
            keyBinding: $b meta;
            wantsToDisplayOnEmptyQuery: false

Done. Now, you can search for classes using regular expressions. In the same way you can manage all other extensions.