Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Platform UI MarkersView"
(New page: = 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, Book...) |
(→Markers View Design Notes) |
||
| Line 8: | Line 8: | ||
* Problems is the main markers view. It is not clear that tasks and bookmarks need to be separate | * 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 | * 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 | + | * 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 | * 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 | * 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). | * 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 | ||
| + | |||
| + | ==Step 1: 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 | ||
Revision as of 15:11, 10 July 2007
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
Step 1: 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