Map view save zoom, location and provider state

[Auriga2]

Prerequisites

• Reviewed the checklist

• Reviewed feedback from the "Sonar Cloud" bot. Note that you have to wait
  for the "CI / Unit Tests") to complete first. Failed Unit tests can be
  debugged by adding the label "verbose logging" to the GitHub PR.

Description of the Change

Map view no longer resets to the default map, default location and default zoom level (4) when the window or pane is resized. This fix disposes the renderer and rebuilds it for each resize.

The Alternate Design eliminates that but it can have issues when moving constellation window between displays with different resolutions, and when reducing the size of the map on certain displays.

Alternate Designs

#2491

Why Should This Be In Core?

User doesn't have to reselect the map from the drop down again and manually zoom to the required location after resizing.

Benefits

Better UX

Possible Drawbacks

Performance limitations if resizing frequently.

Verification Process

1. Open Map view and switch to another map from the map that opened by default (Not necessarily the default map). Zoom in or out to any level except 4, in a different location.
2. Resize the Map view pane or the constellation window and notice that it no longer resets to the map that opened by default.
3. Verify the same behavior after you zoom in/out to a different location in the map that opens by default as well.

Applicable Issues

#2376
#618

[Quasar985]

The function parameters can be final

[Quasar985]

The function parameter can be final

[OrionsGuardian]

Comparing the functionality between this PR and the other PR for the Map View reset issue, I prefer this version, even if it does rebuild the view more often. The end result is cleaner and consistent, and doesn't have the same side-effect issues that are occurring in the other PR.

[Auriga2]

I agree too. Probably we could implement the other option or similar, after #1746

[antares1470]

Comparing the functionality between this PR and the other PR for the Map View reset issue, I prefer this version, even if it does rebuild the view more often. The end result is cleaner and consistent, and doesn't have the same side-effect issues that are occurring in the other PR.

I agree. My only concern will be if the performance hit becomes significant enough to impact usability of the application. From testing I didn't experience that, but its probably something to note (e.g. does a significant number of markers on the map cause notable issues with redrawing every time)

[Auriga2]

I agree. My only concern will be if the performance hit becomes significant enough to impact usability of the application. From testing I didn't experience that, but its probably something to note (e.g. does a significant number of markers on the map cause notable issues with redrawing every time)

In terms of performance, this is same as v3.3 which disposes the renderer and rebuilds it with the default map for each resize. So hopefully there won't be issues.

[antares1470]

Are there situations where we're ok with provider or center being null, or zoomLevel not being at least 0?

I note there are the regular getters above this but I'm thinking that if the answer to the above is no (i.e. there aren't any situations where we want that), then perhaps we should applying those logic checks at the point of setting the values (in the update function) rather than at the get stage. Means you could also set those fields to the defaults in the constructor (which in turn ensures you avoid any errors from calling getters before update is called, and potentially means you don't require the valid boolean).

[Auriga2]

Makes sense. Fixed now.

[sonarqubecloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud