No Business Naming Things

From the newsgroups and bug reports I’ve gleaned that there is some confusion as to how Contexts, Capabilities (Activities), and Perspectives are related. Some people accidentally interchange the terms while others honestly believe they are the same thing. I’d like to shed some light on their relationship.

Perspectives have been around since the time of the dinosaurs (Eclipse 1.0). The driving goal behind Perspectives was to allow plug-in developers to provide a task-driven means of laying out the views, editors, and actions that a user would need to interact with their plug-in functionality. Perspectives can best be though of as the overall task that a user is currently participating in. Ie: Java development, team tools interaction, general resource management. Perspectives are of course totally customizable so that users can tailor the user interface to their particular task requirements.

Contexts are a newer beast, first appearing in Eclipse 3.0. The purpose of Contexts was to allow plug-in developers to advertise in a fine-grained manner what a user was currently doing. Ie: Editing Java source, debugging Java, synchronizing team resources. The state of enabled Context may be used to drive any number of mechanisms. For instance, Context enablement is one of the criteria for key binding enablement and the debug infrastructure uses it to determine whether or not specific debug views should be brought to the users attention. Contexts are never explicitly enabled or disabled by the user. Rather, their enablement is implicitly governed by the users interaction with the Eclipse environment.

Like Contexts, Capabilities first appeared in Eclipse 3.0. The introduction of Capabilities was rife with controversy, however. One of the problems we are facing is that our English namespace is being rapidly depleted and we’re running out of names for new features. We initially chose Activities as the name for Capabilities but found out very late in the 3.0 cycle that the name was already being used by a downstream provider. To avoid confusion, we re-Christened them the documentation and user-interface to be Capabilities and left them as Activities in the extension point and API so as to not break early adopters.

Capabilities are best thought of as an expression of what areas of interest may exist in a product. In this respect they are similar to Perspectives in that the interesting areas often align roughly to the tasks that a user would be able to undertake. Like Contexts, Capabilities are either on or off. The workbench uses this state to determine the visibility of user interface contributions provided by plug-ins. For instance, if the Java Development Capability is disabled then the majority of the Java user interface components will be hidden from the user. I say majority because even after filtering there remains a subset of components that remain visible. We call these components Trigger Points and they are used by the user to express their interest in using additional functionality related to that Capability. For instance, imagine that the Java Development Capability is disabled. Java views would be hidden from the Show View menu, Java Preferences would be hidden from the Preference dialog, etc. Despite this, the New Java Project entry remains visible in the New wizard dialog. Should the user activate this wizard and create a Java project the other Java interface components will immediately become visible and available to the user. In addition to these implicit Trigger Points the Eclipse SDK provides a preference page that allows the user to explicitly customize the enablement of the Capability set.

Looking at the above three descriptions it’s easy to understand why there might be some confusion as to how they are related. Despite each of them having very specific purposes they’re all living in the user task space. If you’re a plug-in developer attempting to improve the ability of your users to interact with your plug-ins functionality keep this in mind:

• perspectives are about layout and easy access to often needed functionality
• contexts are about expressing to the workbench and other interested plug-in what it is your user is currently doing
• capabilities are about filtering undesired functionality until the user expresses an interest in utilizing it

Next: Where to find reference documentation and examples of how these pieces can be woven together coherently.