Add a new DataSelectionListener and use it to manage the selection.

[michael2402]

​diff, ​patch

Commits:

1. ​626c26f: Add a new DataSelectionListener and use it to manage the selection.

Stats:

 .../josm/data/osm/DataSelectionListener.java       | 291 ++++++++++++++++++++
 src/org/openstreetmap/josm/data/osm/DataSet.java   | 302 +++++++++------------
 2 files changed, 422 insertions(+), 171 deletions(-)

[Don-vip]

same question regarding travis status ("build failing")

[michael2402]

Same answer.

I'll have to get travis fixed first, problem is not with the patch. I'm currently working on getting that fixed (finding out why tests are failing, fixing warnings, ...)

[simon04]

Milestone renamed

[bastiK]

Shouldn't this patch SelectionEventManager.java?

[Don-vip]

Milestone renamed

[michael2402]

Updated the patch to the current version.

There are still some calls to fireSelectionChanged() of which I did not figure out why they are there. The selection is completely handled by the DataSet, so there should be no need for this.

I'd also suggest to replace all uses of the static DataSet.addSelectionListener() using SelectionEventManager.getInstance().addSelectionListener(). This now tracks edit layer changes.

[michael2402]

In 12113/josm:

See #13467: Preserve order of removed / added fields for selection events.

[bastiK]

It appears, most (if not all) of the patch has been committed in [12048]. Is this ticked fixed?

[michael2402]

I applied the patch.

So the new interface is already in trunk.

There are still many places using the old SelectionChangedListener. We should decide to drop it completely (which would be what I prefer) or to keep it.

[bastiK]

Replying to michael2402:

I applied the patch.

So the new interface is already in trunk.

Okay, good to know. :)

There are still many places using the old SelectionChangedListener. We should decide to drop it completely (which would be what I prefer) or to keep it.

DatSet.addSelectionListener(SelectionChangedListener) does the same as SelectionEventManager.getInstance().addSelectionListener(DataSelectionListener) so it is redundant, right?

[michael2402]

Replying to bastiK:

There are still many places using the old SelectionChangedListener. We should decide to drop it completely (which would be what I prefer) or to keep it.

DatSet.addSelectionListener(SelectionChangedListener) does the same as SelectionEventManager.getInstance().addSelectionListener(DataSelectionListener) so it is redundant, right?

Sort of.
DataSelectionListener is more advanced and will tell you more about the actual selection changes.
And it will only fire on changes of the edit layer.
Aditionally, it will fire when the edit layer was changed and the selection was changed due to the edit layer change (it fires a unselect old - select new). So components to not need to track the edit layer themselves (solved some bugs in the UI where it did not refresh correctly).

[Don-vip]

In 13925/josm:

fix #13467 - use DataSelectionListener everywhere. Deprecate SelectionChangedListener