Implement annotation grouping.

[Luro02]

This PR implements grouping annotations, which should alleviate the issue with too many annotations from the autograder.

This PR closes #16.

Things that must be done, before this can be merged

• fix or disable sorting of rows, currently very broken
• group annotations with identical messages into a subgroup (so one can bulk remove all annotations that are wrong)

The PR itself was much more work than I had initially expected. A proof-of-concept was implemented in about a day, after that I spent three days trying to solve the following issues:

1. Indices of the rows are not correctly mapped to the model (this broke changing annotations)
2. A NullPointerException occurs when an annotation is removed
3. Rows were not selected correctly

1 has been worked around by using the tree methods, which work flawlessly. 3 has been fixed in a similar way. For 2, there does not seem to be a good solution, I do not even know what the cause for this is. It had been reported in the issue tracker, but they closed it as "not reproducible".

My "hack" is to catch the NPE and return a dummy component which works surprisingly well. I could not observe any problems with this implementation.

[Luro02]

The sorter is completely broken and I dont know how I will be able to fix this.

When the table is sorted, like here:

The collapsible rows dont behave correctly anymore and one is unable to select the correct ones. This is likely related to the broken viewToModelRow function (which I tried to fix in the past, resulting in other things breaking).

Current idea is to implement dedicated code that will reorder the rows manually/rebuild the entire table.

[Luro02]

The PR is ready for review, all mentioned bugs have been fixed.

Here is how it currently looks like:

In addition to merging annotations, I made sure that:

• when removing an annotation from a group, the group doesn't close
• one can bulk remove annotations (select first annotation, then shift click the last one in the list), ctrl+click works too
• removing a group, deletes all annotations in that group
• delete and right press menu call the same code
• changing custom penalty message works
• when after removal a group has only one annotation, the group is replaced by that annotation
• empty groups will automatically be removed
• removal should not destroy the sorting (but the whole tree is not sorted again, would be confusing in my opinion)
• jumping to source code works
• double click on groups doesn't do anything
• when the annotation icon on the left of the code is pressed, the annotation list is scrolled until the now selected annotation is visible (when necessary, groups are expanded as well). This was a minor annoyance that I had with the old table.

Some things I wasn't sure about:

• are the arrow down/arrow up icons correct for the sorting or should they be swapped?
• what should be the order of the sort orders? I assume "alphabetically starting with A", then the reverse and then back to the original order.
• when a line is deleted in the table, should it select the next line? (might be tricky to implement)
• adjust relative size of the columns based on their content

[Feuermagier]

I like this a lot, just one thing: I think it's a bit confusing that there can groups with the same name on the same level or nested within each other. If grouped by custom message, you could show an abbreviated version of the custom message. I'm not sure what to do for classifiers though.

[Luro02]

I like this a lot, just one thing: I think it's a bit confusing that there can groups with the same name on the same level or nested within each other. If grouped by custom message, you could show an abbreviated version of the custom message. I'm not sure what to do for classifiers though.

Hmm, not sure what you mean. The custom message is there, it is just not included in the screenshot.

For the header of a group, it uses the one value (if it is the same for every annotation in it) or the possible values separated by a comma. For the paths I did some extra work, because of how much they have in common (with the naive implementation it would be effectively useless)

[Feuermagier]

Yeah the information is there, but you need to actively look for it (and possibly even scroll horizontally in the table). I think it would be nice if nested groups wouldn't have the title of the parent group, but indicate by what property they where grouped.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[dfuchss]

Functionality is done. Cleanup should be done in a follow-up PR :)