|(4 intermediate revisions by 2 users not shown)|
= Markers View
Design Notes = |+|
= Markers View =
| || |
|−|We are currently looking at some significant changes to how markers are represented in the Eclipse SDK. |+|
are markersthe .
| || |
|−|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 |+|
is the markers view. a of in of to use .
|−|* 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. |+|
markers viewthat the
be in the .
| || |
|−|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== |+|
is the of of columns .
|−|* 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 |+|
*. The display the
|−|* 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 |+|
*. The markers the
|−|* custom columns. The columns shown will be specified by the content provider |+|
*. The the
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 |+|
The pre 3.4 implementation of a view for Tasks, Bookmarks and Problems is not sufficient for how many people are using markers. See the org.eclipse.ui.ide.markerSupport schema for full details.
In 3.4 the MarkerSupportView was added to allow clients to create thier own markers views more suited to thier applications. A MarkerSupportView is created by referring to the markerContentGenerator.
The markerContentGenerator is the base element for defining a custom markers view. When creating a subclass of MarkerSupportView you pass in the id of the markerContentGenerator to use for it.
A markerField is the definition of one of the columns of a MarkerSupportView. A markerField defines