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

user API for slice plugin #1635

Merged
merged 4 commits into from
Sep 15, 2022
Merged

user API for slice plugin #1635

merged 4 commits into from
Sep 15, 2022

Conversation

kecnry
Copy link
Member

@kecnry kecnry commented Sep 9, 2022

Description

This pull request extends on #1401 and provides user-API access to the slice plugin.

Plugin User API docs

TODO:

  • fix failing tests
  • add PR to changelog if before next release, otherwise add new entry (waiting until PR is accepted otherwise to avoid constant merge conflicts)

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 change log needed? If yes, is it added to CHANGES.rst?
  • Is a milestone set?
  • After merge, any internal documentations need updating (e.g., JIRA, Innerspace)?

@kecnry kecnry added this to the 2.11 milestone Sep 9, 2022
@kecnry kecnry force-pushed the api-slice branch 2 times, most recently from ef788a1 to 53c83be Compare September 9, 2022 18:43
@codecov
Copy link

codecov bot commented Sep 9, 2022

Codecov Report

Base: 86.34% // Head: 86.32% // Decreases project coverage by -0.01% ⚠️

Coverage data is based on head (c56b237) compared to base (f1849e8).
Patch coverage: 100.00% of modified lines in pull request are covered.

❗ Current head c56b237 differs from pull request most recent head 4c22449. Consider uploading reports for the commit 4c22449 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1635      +/-   ##
==========================================
- Coverage   86.34%   86.32%   -0.02%     
==========================================
  Files          95       95              
  Lines        9622     9611      -11     
==========================================
- Hits         8308     8297      -11     
  Misses       1314     1314              
Impacted Files Coverage Δ
jdaviz/configs/cubeviz/plugins/slice/slice.py 96.90% <100.00%> (+0.16%) ⬆️
...default/plugins/metadata_viewer/metadata_viewer.py 94.50% <0.00%> (-0.24%) ⬇️
jdaviz/configs/imviz/plugins/catalogs/catalogs.py 95.58% <0.00%> (-0.07%) ⬇️
jdaviz/configs/default/plugins/viewers.py 95.53% <0.00%> (-0.04%) ⬇️
jdaviz/app.py 91.79% <0.00%> (-0.02%) ⬇️
...daviz/configs/default/plugins/collapse/collapse.py 100.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

@kecnry kecnry marked this pull request as ready for review September 9, 2022 21:01
Wavelength of the current slice. If setting, will update automatically to the nearest
slice.
* ``setting_show_indicator``
Whether to show indicator in spectral viewer even when slice tool is inactive.
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like this only changes the status of the indicator when it is inactive, is that the intended functionality?

Copy link
Member Author

Choose a reason for hiding this comment

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

yes. If it is set to True, the line changes from blue to orange based on whether the slice tool is active to click and drag. If it is set to False, the line disappears when inactive (but still appears and is orange when active). Any suggestions to clarify the wording (both here and in the UI)?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think just removing the word "even" should be enough. Just wanted to clarify!

Copy link
Member Author

Choose a reason for hiding this comment

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

agreed that is simpler, made the change!

* ``wavelength``
Wavelength of the current slice. If setting, will update automatically to the nearest
slice.
* ``setting_show_indicator``
Copy link
Contributor

Choose a reason for hiding this comment

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

Now that this is public, should we remove the redundant "setting" prefix?

Suggested change
* ``setting_show_indicator``
* ``show_indicator``

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm not sure. I have been using this prefix across all plugins for any switch that goes in the settings expansion panels of that plugin. But we can remove the prefix from all of them, or could invent a plugin.settings container to nest them?

Copy link
Contributor

Choose a reason for hiding this comment

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

Is that a lot of extra work? It is just a little confusing for me to see some with "settings" and some not. To me, they are all settings. I don't think API-wise, the user cares if it is nested in Settings panel or not.

Copy link
Member Author

Choose a reason for hiding this comment

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

I like having some distinction between switches that only affect visualization or how many details are shown, verse inputs that actually affect the output of the plugin. But maybe just ordering them in the API docs could accomplish that without the prefix or nesting. I'll give it some thought.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I support dropping the setting_ prefix, but don't feel too strongly about it.

Copy link
Member Author

Choose a reason for hiding this comment

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

ok, that would affect slice, spectral extraction, and plot options... none of which have been merged yet, so I'll update the other 2 open PRs separately as well.

jdaviz/configs/cubeviz/plugins/slice/slice.py Outdated Show resolved Hide resolved
Comment on lines 30 to 31
Wavelength of the current slice. If setting, will update automatically to the nearest
slice.
Copy link
Collaborator

@rosteen rosteen Sep 15, 2022

Choose a reason for hiding this comment

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

Suggested change
Wavelength of the current slice. If setting, will update automatically to the nearest
slice.
Wavelength of the current slice. When setting this value directly, it will update
automatically to the value at the nearest integer slice index.

If we keep the setting_ prefix, this phrasing could cause some confusion (is "setting" here talking about the same thing as in the attribute names?). My suggestion might be a little overly wordy/precise, but might be clearer.

Copy link
Member Author

Choose a reason for hiding this comment

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

This was confusing, I committed a slightly modified version of your suggestion, let me know what you think.

Copy link
Collaborator

Choose a reason for hiding this comment

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

New wording sounds good to me.

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.

Looks good to me now, thanks!

@rosteen
Copy link
Collaborator

rosteen commented Sep 15, 2022

Just needs a changelog update before merging. Edit: beat me to it, I hadn't refreshed!

@kecnry kecnry merged commit 1cb9d95 into spacetelescope:main Sep 15, 2022
@kecnry kecnry deleted the api-slice branch September 15, 2022 15:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants