Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ensure footprints display when added before linking #2797

Merged
merged 10 commits into from
Apr 17, 2024

Conversation

gibsongreen
Copy link
Contributor

@gibsongreen gibsongreen commented Apr 11, 2024

Description

This PR is to address when footprints are added via API prior to linking by WCS. Only the last footprint added was visible in the viewer once linked, even when all footprints are set to be visible.

Screen.Recording.2024-04-11.at.11.42.21.AM.mov

Change log entry

  • Is a change log needed? If yes, is it added to CHANGES.rst? If you want to avoid merge conflicts,
    list the proposed change log here for review and add to CHANGES.rst before merge. If no, maintainer
    should add a no-changelog-entry-needed label.

Checklist for package maintainer(s)

This checklist is meant to remind the package maintainer(s) who will review this pull request of some common things to look for. This list is not exhaustive.

  • Are two approvals required? Branch protection rule does not check for the second approval. If a second approval is not necessary, please apply the trivial label.
  • Do the proposed changes actually accomplish desired goals? Also manually run the affected example notebooks, if necessary.
  • Do the proposed changes follow the STScI Style Guides?
  • Are tests added/updated as required? If so, do they follow the STScI Style Guides?
  • Are docs added/updated as required? If so, do they follow the STScI Style Guides?
  • Did the CI pass? If not, are the failures related?
  • Is a milestone set? Set this to bugfix milestone if this is a bug fix and needs to be released ASAP; otherwise, set this to the next major release milestone. Bugfix milestone also needs an accompanying backport label.
  • After merge, any internal documentations need updating (e.g., JIRA, Innerspace)?

@gibsongreen gibsongreen added this to the 3.9.1 milestone Apr 11, 2024
@github-actions github-actions bot added imviz plugin Label for plugins common to multiple configurations labels Apr 11, 2024
@gibsongreen gibsongreen added bug Something isn't working plugin Label for plugins common to multiple configurations 💤 backport-v3.9.x on-merge: backport to v3.9.x and removed plugin Label for plugins common to multiple configurations labels Apr 11, 2024
Copy link

codecov bot commented Apr 11, 2024

Codecov Report

Attention: Patch coverage is 90.47619% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 88.86%. Comparing base (a6de416) to head (ee1d01c).
Report is 4 commits behind head on main.

❗ Current head ee1d01c differs from pull request most recent head 40ed3a4. Consider uploading reports for the commit 40ed3a4 to get more accurate results

Files Patch % Lines
...viz/configs/imviz/plugins/footprints/footprints.py 90.47% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2797      +/-   ##
==========================================
+ Coverage   88.82%   88.86%   +0.03%     
==========================================
  Files         111      111              
  Lines       16879    16894      +15     
==========================================
+ Hits        14993    15013      +20     
+ Misses       1886     1881       -5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Comment on lines 188 to 192
# When fp(s) added via API before WCS link. Overlays visibility & is_active
# can be True, but only last fp will display. This ensures all fp(s) display
if not self.is_pixel_linked:
for choice in self.overlay.choices:
self.overlay.selected = choice
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we call the method internally so that the selected choice isn't affected (I'm assuming this works because it triggers the observe on overlay_selected)? If that isn't possible, can we at least restore the user-selection after this for-loop?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is triggering the observe. I am seeing that without changing the selected choice and calling the method internally, the only overlay that displays is the last one added based on preset_args_changed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we have the internal method take the name of the overlay and default to overlay_selected so that we can trigger the logic without changing the selection?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see gibsongreen#1 for a rough idea of how this could work (although I didn't have a test case, so haven't tested if it still fixes the bug - a regression test would be great if possible!)

Comment on lines 190 to 194
restore_choice = self.overlay.selected
if not self.is_pixel_linked:
for choice in self.overlay.choices:
self.overlay.selected = choice
self.overlay.selected = restore_choice
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did see that if you go from pixel -> wcs (change the overlay selected to any but the last) -> pixel the overlay selected would go to the last added as well, so this should now take care of that.

Comment on lines 191 to 193
for choice in self.overlay.choices:
if len(self.overlay.choices) > 1:
self._change_overlay(overlay_selected=choice)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if there aren't any choices, then the for-loop shouldn't even enter. It might also be a good idea to add a comment here so we don't think this is changing the selection (feel free to edit the text to whatever you think makes sense).

Suggested change
for choice in self.overlay.choices:
if len(self.overlay.choices) > 1:
self._change_overlay(overlay_selected=choice)
for choice in self.overlay.choices:
# trigger the update without actually changing the user-selection
self._change_overlay(overlay_selected=choice)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When Imviz is instantiated in a notebook or test, the default overlay is temporarily in self.overlay.choice(and it is NoneType at this time). So to make sure that a TypeError exception isn't thrown I added this conditional.

I will add a comment now for some clarity on what this loop is doing.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so it enters the loop and then the choice disappears before _change_overlay is called?

Copy link
Contributor Author

@gibsongreen gibsongreen Apr 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default does get passed into _change_overlay, it does go through creating a new entry, at the end of creating a new entry, since there is now 1 entry, the overlay tries to center_on_viewer. And when this happens the viewer.get_center_skycoord is what is actually NoneType (I mistakenly said it was the overlay).

In the case that no overlay is added in the API before WCS linking, the default that gets created does still center on the viewer (so this does still trigger correctly if there is only 1 overlay).

Copy link
Member

@kecnry kecnry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM pending the one comment I left (which isn't crucial). Thanks for tracking this down!

Copy link
Collaborator

@rosteen rosteen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved but I'd prefer to see tests pass after #2809 gets merged before merging this.

Edit: eh, I guess as long as it's only the one know failure, go ahead and merge.

@gibsongreen
Copy link
Contributor Author

gibsongreen commented Apr 17, 2024

Approved but I'd prefer to see tests pass after #2809 gets merged before merging this.

Edit: eh, I guess as long as it's only the one know failure, go ahead and merge.

I just made a small change so this will go through the CI now and make sure they all pass!

@gibsongreen gibsongreen merged commit 7e3fb1a into spacetelescope:main Apr 17, 2024
13 of 14 checks passed
meeseeksmachine pushed a commit to meeseeksmachine/jdaviz that referenced this pull request Apr 17, 2024
kecnry pushed a commit that referenced this pull request Apr 17, 2024
#2815)

Co-authored-by: Gilbert Green <42986583+gibsongreen@users.noreply.github.com>
rosteen pushed a commit to rosteen/jdaviz that referenced this pull request Apr 18, 2024
)

* when footprint added before linking, make sure they display when link is updated

* add change log

* add ability to restore overlay selection

* call _preset_args_changed instead of changing selection

* internalize bug fix and add test coverage

* add comment explaining link change loop

* change fp to footprint in comments

* address case where default overlay is created in init

* change np.ones() to np.ones(()) for testing

* trigger CI

---------

Co-authored-by: Kyle Conroy <kyleconroy@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working imviz plugin Label for plugins common to multiple configurations Ready for final review 💤 backport-v3.9.x on-merge: backport to v3.9.x
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants