-
Notifications
You must be signed in to change notification settings - Fork 76
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
Conversation
ef788a1
to
53c83be
Compare
Codecov ReportBase: 86.34% // Head: 86.32% // Decreases project coverage by
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
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. |
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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)?
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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`` |
There was a problem hiding this comment.
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?
* ``setting_show_indicator`` | |
* ``show_indicator`` |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Wavelength of the current slice. If setting, will update automatically to the nearest | ||
slice. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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!
Just needs a changelog update before merging. Edit: beat me to it, I hadn't refreshed! |
Description
This pull request extends on #1401 and provides user-API access to the slice plugin.
Plugin User API docs
TODO:
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.
trivial
label.CHANGES.rst
?