Platform UI MarkersView
Markers View Design Notes
We are currently looking at some significant changes to how markers are represented in the Eclipse SDK.
The current implementation of a view for Tasks, Bookmarks and Problems is not sufficient for how many people are using markers.
Some of the key issues in no particular order are
- Problems is the main markers view. It is not clear that tasks and bookmarks need to be separate
- There are a lot of views in even moderately sized Eclipse applications. Consolidating these 3 views into one view would reduce clutter
- Large applications have a very large amount of marker types to contend with and get a lot of updates that are just confusing to users as a result of having multiple builders in use
- Filtering is too complex. There should be some good default filters and filtering in general needs to be simplified
- Working set support is not tied to working set selection but rather resource selection
- Columns are not configurable or expandable. Many fields (such as location) are not relevant to some markers with others need information we are not showing (like sourceId).
- There is no markers view API for applications to expand
An extendable markers view
The first step to this is to make a single, multi-instance markers view that replaces the problems, tasks and bookmarks view. The content would be specified by an extension in the markerSupport extension point.
This content needs to support
- different default values for different perspectives. For instance the tasks content would be in use in the Resource perspective and the problems content would be used by the Java perspective.
- activities so that content can be filtered out
- a limited set of markerTypes to prevent transient markers being shown from multiple builders
- specification of the columns to show. Many RCP applications have other relevant marker information to show (such as IMarker#sourceID) which is not currently available.
Other new features not currently available
- default filtering. We currently support this but do not use it in the SDK. The most popular combination is all errors and warnings on selection
- no marker limits. With better default filtering all of the markers will be shown. As the tree is now virtual (see below) the performance issues of large marker sets should be less of an issue
- custom columns. The columns shown will be specified by the content provider
- filtering based on displayed columns. The filtering dialog will display filtering for all columns
Use of the newer platform features
- Commands. The markers view will now use the new commands structure so that other contributors can add to it's menus as desired without having to subclass
- Virtual Tree. The tree will now be virtual eliminating the need for marker limits
- Forms. The new filter page will be forms based for easier contribution and navigation