This Bugzilla instance is deprecated, and most Eclipse projects now use GitHub or Eclipse GitLab. Please see the deprecation plan for details.
Bug 422289 - [IDE] copying/pasting elements from the Markers view should preserve their listed order
Summary: [IDE] copying/pasting elements from the Markers view should preserve their li...
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.3.1   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 4.4 M4   Edit
Assignee: Paul Elder CLA
QA Contact: Paul Elder CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-21 16:00 EST by John Glassmyer CLA
Modified: 2013-12-10 13:18 EST (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Glassmyer CLA 2013-11-21 16:00:26 EST
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.
Comment 1 Paul Elder CLA 2013-11-22 11:39:38 EST
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).
Comment 2 John Glassmyer CLA 2013-11-22 11:51:23 EST
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.
Comment 3 Paul Elder CLA 2013-12-03 09:37:19 EST
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.
Comment 4 Paul Webster CLA 2013-12-09 09:08:58 EST
Eric, could you please review this for Paul?

Thanks,
PW
Comment 6 Paul Elder CLA 2013-12-10 13:18:39 EST
Verified in 4.4.0.I20131209-2000