Description Martin Aeschlimann 2005-12-08 09:32:15 EST

20051208

This bug summarizes a mail-discussion that I, Tod and Markus had about the hierarchical problems view.

The main motivation for a hierarchical problems view is to group problems in the problem view so that it's easier to see and work on a subset of them.

The approach of building multi level hierarchies e.g. 
Java Problem
   Error
      NLS Problem
        File1
has some major drawbacks:
- There is no one-fits-all hierarchy. This hierarchy for example would not help you if you want all Errors in a file. Users would want to configure their hierarchies, involving sophisticated UI. I think this should be avoided.
- Deep hierarchies are usually not practical. Lots of expanding, collapsing involved. Markers spread over several nodes.
- The categories in this tree must all be disjunctive. This is mostly not true. E.g. there could be NLS problems that are warnings and some that are errors.

The suggestion for a more lightweight hierarchical problem view is the following:

Allow only a one level deep tree that groups for one category.

A category has a name ('Java Problem Kind')
and defines groups ('NLS problem' 'Unused Element Problem' 'Unspecified')
The catogory can be asked in which group a marker goes. If the category doesn't know a maker, it will assign it in the 'Unspecified' group.

Categories are contributed. Some categories are provided by the platform, like:
'Problem type' ('Java problem', 'C Problem' .....)
'Location' (all resources, 'Proj1/fold1/res1', ... )
'Severity' ('Error', 'Warning...'

The problem view can be grouped by a category. That means the tree root nodes will be the groups, markers will be children of their group.

A category can be enabled to be shown in the table as a column. The header will be the category name. The label in the column for the marker will be the group name or something more specific (-> API Category.getColumnLabel(IMarker)).

To enable a new grouping in the table, the user can click on the column header. Or, to avoid that first a column has to be enabled, a combo box over the tree could contain all possible categories to group for.

------
Example:
Lets say we have the following columns:
    'severity', 'resource', 'description', 'marker type', 'java category'
The user configured these columns and their order. He e.g. added 'java category', removed 'line number'

Clicking on 'severity' introduces groups 'Error', 'Warning', 'Info' ...that become the root node in the tree
Error
      problem 1..... (normal line with all columns)
      problem 2...
Warning
      problem 3...    
.. 

Clicking on 'marker type' sorts using groups 'Java Problem', 'C problem',....
Java Problem
          problem 1.....
          problem 2.....
C problem
        ..

Clicking on 'java category' using groups 'NLS Problems', 'Unused problems' but also 'Uncategorized' for all markers that don't fit in any of the groups
NLS Problem
          problem 1.....
          problem 2.....
Unused problems
          problem 3....
Uncategorized
          problem 4.....
          problem 5....

or (advanced ideas)

Clinking 'resource' introduces a resource tree
com
  ibm
    xy
      A
          problem 1.....
          problem 2.....
      C
         ...

Clicking on description doesn't group at all, just sorts (for example, just to illustrate the possibilities)
          problem 1.....
          problem 2.....
          problem 3....
          problem 4.....
--------------

One problem is plugin activation for the contributed categories. The problem view has only some of the built in categories as columns by default. But the user can add more columns (depending on what he's working on). When shuting down and restoring Eclipse again, a view should try to restore the previous state. If the view was grouped by a contributed plugon, or if a contributed category is used as column, this would mean we would have to lead its plugin.

There are the following appoaches:
- We don't try to restore the problems view's grouping if the used category hasn't been loaded yet. A default grouping or no grouping will used instead
- We don't show columns on restore if its category hasn't been loaded yet. Either  it will be removed (the user would have to add it again) or it will be grayed out, labels will say 'Unspecified'
- A category can give a hint that it is allowed to be loaded if markers of some spcified types are available. The availabilty of a java.problem marker is a good indication that the Java UI plugin will be loaded very soon.