Community
Participate
Working Groups
The order in which elements appear when pasted should match the order in which they were listed in the Markers view when they were copied. Currently, if I sort the Markers view (e.g. by Description) and then copy-paste a selection of listed markers/problems into another application, they are pasted in a different order than the order in which the Markers view lists them. This is inconvenient for the user, for example when comparing two lists of Markers from two different versions of a project. The current lack of ordering in pasted elements means the user has to manually sort the elements in the destination application. Probably the same thing applies to the Problems view and/or to other list views in Eclipse.
Happens in the Problems view, too, and in every view derived from ExtendedMarkersView. Looks like this got injected in 3.8/4.2 by the fix for bug 364039. The method org.eclipse.ui.internal.views.markers.ExtendedMarkersView.getSelectedMarkers() is using a HashSet() to collect markers (as opposed to marker categories) from the tree selection. This, of course, randomizes the list of markers. Prior to the bug364039 fix, an ArrayList was used. Presumably, the HashSet() was used to prevent insertion of duplicates. Duplicates can happen because the bug 354039 fix changes the semantics of a selected category - it now implies that all the category's children are selected (whether or not they physically are).
My naive response would be that a LinkedHashSet would seem to achieve both goals of preserving order and ensuring uniqueness. Having said that, (I am not familiar with the code so I don't know if doing so indeed makes sense, but) the idea of using a HashSet to ignoring repeated occurrences in a tree structure seems a bit simplistic to me.
Pushed fix to gerrit: https://git.eclipse.org/r/19253 The fix copies selected items in the order they appear in the view. HOWEVER, when a category is selected, and the view displays only a portion of the markers in that category because the view's display limit, only the displayed markers are sorted. The remaining markers are included in the copy after the sorted ones, but in no definite order. The fix, instead of using a LinkedHashMap, uses knowledge of the structures selection (at most two levels, categories containing markers, or just markers) and an array list. This proved to be more efficient than the LinkedHashMap.
Eric, could you please review this for Paul? Thanks, PW
Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=c3e3c447c3e39bc89b298c8a03499621c83724f8 Thanks Paul PW
Verified in 4.4.0.I20131209-2000