With this PR, selections made in the ControlPanel widget will be reflected in both of the ContactMap widgets, and moving the selection in one ContactMap will move it in the other.
There was some refactoring done in the second commit. You can read about it in the full commit message, but the short version is this:
The GeometryCanvas and ContactMapCanvas widgets now report and accept selections in the same format (with ContactMap taking on the extra complexity and inefficiency to match GeometryCanvas's format). This could be a problem in the future with really large data sets, and could be a problem now if you consider ugly code a problem. Once this sprint is done with, we should take the time to work out how all the components are going to communicate selections with one-another and find something that works the best for all components. Probably through the introduction of a dedicated type representing a selection (different than what the Selection class does now).
With this PR, selections made in the ControlPanel widget will be reflected in both of the ContactMap widgets, and moving the selection in one ContactMap will move it in the other.
There was some refactoring done in the second commit. You can read about it in the full commit message, but the short version is this:
The GeometryCanvas and ContactMapCanvas widgets now report and accept selections in the same format (with ContactMap taking on the extra complexity and inefficiency to match GeometryCanvas's format). This could be a problem in the future with really large data sets, and could be a problem now if you consider ugly code a problem. Once this sprint is done with, we should take the time to work out how all the components are going to communicate selections with one-another and find something that works the best for all components. Probably through the introduction of a dedicated type representing a selection (different than what the Selection class does now).