-
Notifications
You must be signed in to change notification settings - Fork 74
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
Data Dropdown Component #1313
Data Dropdown Component #1313
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1313 +/- ##
==========================================
+ Coverage 84.60% 84.64% +0.03%
==========================================
Files 91 91
Lines 7836 7878 +42
==========================================
+ Hits 6630 6668 +38
- Misses 1206 1210 +4
Continue to review full report at Codecov.
|
# expose the row to vue for each of the viewers | ||
self.app.state.settings = {**self.app.state.settings, 'mosviz_row': msg.selected_index} |
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.
would be nice to store this under something other than "settings", but creating a top-level traitlet for this in the app is too config-specific. Open to other suggestions - but it must be a traitlet that we can pass through into container.vue
.
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 have no better suggestion. Let's do this for now and see.
if (this.$props.viewer.config === 'mosviz' && item.meta.Plugin === undefined) { | ||
return false | ||
} |
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.
should the delete button be disabled in other cases? Perhaps for all non-plugin data entries? Or at least for the flux cube in cubeviz?
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.
Disabling things to prevent users shooting self on foot (within reason) is probably a good thing.
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... I'm just not sure what cases qualify as that vs an expected use. If the user loads multiple data entries from the API, should they be able to delete those (but maybe just not the last entry which would result in no data in the app)?
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.
Maybe we have to ask POs... 😬
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 has since been changed to only show the delete button for plugin outputs - for now. If we want to enable deleting of other data entries, we'll need to think about how to handle linking, etc, and how to prevent the app from getting in an unusable state (perhaps by forbidding deleting the reference data, or the last entry, etc).
7fcf974
to
85cf207
Compare
jdaviz/app.py
Outdated
if 'Identifier' in component_ids: | ||
typ = 'table' | ||
elif ndims == 1: | ||
typ = '1d spectrum' | ||
elif ndims == 2: | ||
typ = '2d spectrum' if 'Wavelength' in component_ids else 'image' | ||
elif ndims == 3: | ||
typ = 'cube' | ||
else: | ||
typ = 'unknown' |
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.
reviewers (cc @pllim): please try to break this logic and preferably come up with a more robust solution
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.
If we want to stick with APE 14, Stuart Mumford said our best bet is the world_axis_physical_types
attribute values.
For an image data, Data.coords.world_axis_physical_types
gave me ['pos.eq.ra', 'pos.eq.dec']
, while the example Mosviz notebook 2d spectrum gave me ['em.wl', None]
. Full list of possible values appear to be listed at https://github.com/astropy/astropy/blob/main/astropy/wcs/wcsapi/data/ucds.txt . Do we want to go this route?
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'd be happy with either this or the current WCS-length check. If you'd prefer this, I can switch to it, just let me know!
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.
Let's just stick with what you have unless @astrofrog has a better idea. WCS checks might fail if WCS itself is wonky.
467335f
to
87e8c5d
Compare
I am unable to have a moment map and cube selected in the same image viewer in cubeviz. Is anyone else running into that error or just me?
|
@javerbukh - yes I saw that too, that is the error that I asked about. It doesn't seem to always happen, but does seem to happen more here than in main. I suspect it might have to do with the order messages are processed, but I haven't had the chance to dig too much. If anyone familiar with this part of the code has ideas, please let me know! |
Is the first selected data automatically become the new reference data? Is there a way to make sure the cube gets selected first before everything else? If that is not the cause, then we need some debugging to find out what is the pattern that triggers this traceback. |
Here is a crazy thought: For the more rigid viz configurations like Cubeviz and Mosviz, we can disallow deselection of certain data. For example, the flux cube will always be in the flux viewer, and so on. Then maybe we don't have to worry about order of things if the reference data is always unchanging (if indeed it was the unpredictability of what becomes reference data on select/deselect that causes this problem). |
I like that idea, except right now we rely on replacing the default cube in order to show output from the plugins. But if its a matter of what order they get added to the viewer, I can probably add logic here to ensure that IF both a cube and non-cube are checked, that the cube is the first entry (or whatever is needed). |
I am now consistently seeing the same behavior on main when plotting a moment map on top of a cube, so will create a separate issue for that as I think this PR just exposed that use-case and I don't think it actually introduced the bug. EDIT: #1323 |
fc21ddc
to
d79b7a4
Compare
* plugin output data entries are tied to the row at which the were created * switching rows automatically re-selects _all_ plugin data entries for that given row (and de-selects and filters out all plugin results from the previous row) * model fitting and gaussian smooth now include the data label in the default label (so that switching rows proposes a new default label instead of overwriting)
* menu defaults to only showing those belonging to the current row (including plugin results), but can be expanded to include (and plot) items from other rows * hiding extra rows in the menus automatically "unchecks" them (removes them from the plot)
* see added inline comment
775d6bc
to
f60d51d
Compare
now that spacetelescope#1325 is merged and rebased Co-authored-by: P. L. Lim <[email protected]>
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.
Couldn't break it, great work!
@camipacifici claimed she broke it, so let's wait to hear back from her first. |
Looks like the NIRISS parser has separate loading logic, so I'll need to parse the row numbers there too. I'll work on that and should get that in before we merge, but everything besides the parser should should remain unaffected. |
* and only show "show from other MOS rows" if there are entries... since NIRISS can have only a single image data entry
905cd1f
to
6eca4b1
Compare
Works great now! |
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.
# expose the row to vue for each of the viewers | ||
self.app.state.settings = {**self.app.state.settings, 'mosviz_row': msg.selected_index} |
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 have no better suggestion. Let's do this for now and see.
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.
* have to use id instead of reference in the title
Co-authored-by: P. L. Lim <[email protected]>
a7b14b2
to
95259a1
Compare
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.
Imviz bug is fixed. Thanks!
Description
This pull request improves the functionality of the per-viewer data dropdown menu. It replaces the checkmarks with the eye icon used throughout the rest of the app, adds a delete button where allowed (plugins handle reacting to deleted data entries if they use the DatasetSelect component), hides the menu entirely in some cases (mosviz viewers except for the 1D spectrum-viewer), and filters to only applicable entries inside the menu itself.
New styling and delete button:
Screen.Recording.2022-05-13.at.1.25.02.PM.mov
Filtered entries for cubeviz (only flux cube is available in spectrum viewer, plugin results are filtered based on data shape/type):
Screen.Recording.2022-05-13.at.1.28.03.PM.mov
Replace vs multi-select:
Screen.Recording.2022-05-13.at.2.38.36.PM-1.mov
Mosviz filtered to active row (including plugin results):
Screen.Recording.2022-05-14.at.12.05.21.PM-1.mov
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
?