E4/Eclipse Application Model

I am currently merging the content of this page into E4/Eclipse_Application_Services and subpages. -- Boris Bokowski

• • For instance, IExtensionRegistry, IAdapterManager, IProgressService and IPreferencesService seem to be similar in that they are all very low-level, non-UI services.

Selection

ISelectionService - Listening to the current selection

Adapting objects

IAdapterManager - adapt an object (typically, the current selection) to a type that is relevant to the current plug-in

Scheduling background work

IProgressService - Schedule work in a way that is visible to the user Job, IJobManager - schedule and manage background jobs

Help

IWorkbenchHelpSystem

Undo/Redo

IWorkbenchOperationSupport

Preferences

IPreferencesService - retrieve and modify preferences

Handlers

IHandlerService - register a handler for a global command like Copy/Paste

UI Contributions

IMenuService - programmatic contribution to menus and toolbars

Open web pages

IWorkbenchBrowserSupport

Decorations

IDecoratorManager

Common UI Elements

Wizard framework, Dialogs --- Added - KevinM

Dynamic enablement

IExtensionTracker - ability to react to components coming and going at runtime

UI state persistence

IDialogSettings, IMemento - Persistence of UI state: layouts, dialog sizes, viewer selection and expansion state

Extension registry

IExtensionRegistry - registering and accessing extensions and extension points

Notification Service

Initially contributed by Mik Kersten, for questions use: bug 233142

Problem

Some applications need to inform the user of events in the workbench that may require attention, whether or not the workbench is visible. An increasingly standard way of doing this is to use a desktop notification popup, often appearing for a fixed amount of time in the bottom-right hand of the window. As an example, Mylyn has a custom notification mechanism to inform the user when a Bugzilla report has a new comment. The popup shell is now part of the reusable org.eclipse.mylyn.commons.ui plug-in, and could be moved into Platform (see bug 177974).

In Eclipse UI land, the need for a notification mechanism boils down to some view part IWorkbenchPart requesting attention from the user. UI Experience on Mylyn indicates that it is better to have interactivity come from the pat itself, rather than making the user interact with the tiny and transient popup. In other words, the popup becomes an overview link to one or more notification items whose details are present in the part. The part can be a view, as is the case with Mylyn's Task List, or with a view that shows an event log and desires to inform the user of new events, or with a view that wants to inform the user of progress completion as could the Synchronize view. Or it could be an editor, as is the case with Mylyn's task editor which can show incoming notifications.

Proposal

We already have examples of progress support for views such as Synchronize, whose title will go italics for the duration of a synch. We also have some support for this in editors with form's busy spinners and Mylyn's busy spinners in the editor tab (see bug 175592). The proposed Notification Service would build on this idea to make it possible for a view to queue and display notifications on progress and incoming events.

Focus Service

Initially contributed by Mik Kersten, for questions use: bug 233142

Problem

Mylyn provides a task-focused interface for Eclipse, which affects the way that view filtering, expansion and decoration work. This boils down to viewers and editors showing only the structural information relevant to a task (e.g. Bugzilla report) instead of all of the underlying information available in the corresponding content provider(s).

The following resources provide an overview of the facilities and their impact on viewers and a summary is provided below.

• A user-centric overview of the UI is in the tutorial article: http://www.ibm.com/developerworks/java/library/j-mylyn2/
• Detailed description of the facilities is in the PhD theis: http://kerstens.org/mik/publications/2007-01-mik-thesis.pdf (pages 39-40)

The following task-focused interface mechanisms affect views and viewers:

• Filtering: uninteresting elements are filtered from the view by an InterestFilter which is applied when the view is focused. Applying the interest filter causes all other viewer filters to be removed, since the InterestFilter hides all elements by default. Filtering requires the view to be lazily refreshed based on task context model changes in addition to content changes.
• Expansion and linking: focused viewers always have their nodes expanded by default and are always linked to the editor, since they are much less likely to show a scrollbar.
• Decoration: all focused viewers use a lightweight platform decorator to indicate interest level (e.g. gray is uninteresting and bold font is a very interesting element).
• Ranking: sort order can be changed to bring the most interesting elements to the top (e.g. in a table viewer or a content assist list)

The following task-focused mechanisms work on editors:

• Folding: uninteresting elements are automatically folded away in textual editors.
• Filtering: uninteresting elements are automatically filtered from graphical editors.

The following task-focused interface mechanisms affect the workbench:

• View management: views are automatically focused (i.e. facilities listed above are applied) when a task is activated.
• Editor management: open editors are automatically matched to the task context (e.g. all closed when a task is deactivated, all restored when reactivated, if an element decays in interest the editor auto closes).
• Perspective management: perspectives are automatically associated with tasks and activated when tasks are switched.

Proposal

Currently Mylyn makes heavy use of Platform internals to support the task-focused interface. In places it leverages or overrides workbench behavior, as with it's management of mementos for restoring editors. In other places it needs to gain reflective access to hidden parts of the workbench, as with the need to add decorators and filters to the Markers views. The proposed Focus Service would remove the need for internals and make it possible to apply the focus mechanisms to a viewer or other workbench facility if that viewer met the service's simple contract (e.g. the view part contains one or more structured viewers), and provide the focus service access to the required UI mechanisms without overly exposing internals (e.g. injecting the task context model refresh policy into the viewer alongside its content model refresh policy).

Other Services not yet Decided on

• From Architecture Council/Minutes May 15 2008#Eclipse Application Model:
  • Capabilities
  • Content Types, Associations
  • Markers
  • Workspace, Resources (related to Team Support)
  • Launching Framework
  • Core Variables / Launch String Substitution
  • EFS (core.filesystem)
  • OSGi Stuff (NLS, ServiceTracker, Bundle States / Activator / Classloader; Log; State Location)

• The standard bundle layout also seems part of the Application Model ("how Eclipse is built"): MANIFEST.MF and Eclipse-specific extensions, Eclipse.inf, Features etc (related to Provisioning / Update / Plugins, Products, Features)

Notes from e4 break out session

• Missing: Roles, logging, Usage monitoring, Life cycle, Transactions
  • Does Views and Editors belong to that list?

Data model (a rest service)

- Adapting object
- Selection (currentSelection)
- UI Contributions
- Decorations
- Common UI Elements
- Persist State 
- Extension Registry
- roles

Command Bus (a javascript function)

- Selection (change)
- Undo/Redo
- Handlers
- Dynamic enablement
- Notification Service
- Focus service
- logging
- usage monitoring