-
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
stylized layer icons in legend (future data-menu) #3220
Conversation
256c41b
to
5b77543
Compare
This is now ready for reviews (see notes in description about known buggy behaviors which likely will be follow-up efforts unless anyone has concerns). I'm leaving this in draft since we want to defer merge until after the 4.0 release. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3220 +/- ##
==========================================
+ Coverage 88.62% 88.64% +0.01%
==========================================
Files 125 125
Lines 18775 18789 +14
==========================================
+ Hits 16639 16655 +16
+ Misses 2136 2134 -2 ☔ View full report in Codecov by Sentry. |
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 so far (given the caveats listed in the description).
</div> | ||
</template> | ||
|
||
<style scoped> | ||
.viewer-label { | ||
display: block; | ||
float: right; | ||
background-color: #c3c3c3c3; | ||
width: 24px; | ||
background-color: #c3c3c32c; |
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 this change intentional?
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, this adds transparency to the existing gray
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 we specify cursor: default
until the icons are clickable (and then pointer
)?
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.
good idea, done via passing disabled
to the underlying v-btn
.
/* follow-up: use actual colors from the DQ plugins */ | ||
color_or_cmap = 'rainbow' |
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 what color DQ should get. We could take the first N colors from the DQ colormap like you're probably saying in this comment, but they're (intentionally) random, and this might not be the most visually meaningful way to represent DQ.
return 'repeating-linear-gradient(30deg, rgba(0,0,0,0.4), rgba(0,0,0,0.4) 8px, transparent 8px, transparent 8px, transparent 10px)' | ||
} | ||
}, | ||
colorBackgroundStyle(colors, cmap_samples) { |
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 don't expect that these loops to evaluate the colormap for the icons cost much. But is there a way to prove to ourselves that this is true?
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.
we could try to profile it? All this is doing though is taking the input lists generated in python and joining them into a string, with a bit of math to set the widths of each entry, so I really don't expect it to show up in anything.
may eventually replace layer-viewer-icon
* will eventually be "View data layers and subsets" according to specs, but for now will just omit tooltip until the data-menu is implemented
currently just stylizes as a rainbow colormap, we could eventually replace this with the actual colors defined in the DQ plugin, but that would require quite a few callbacks to update styling at each change of any color in the list or adding/removing flags, etc
for now this will mimic z-ordering (unless layers are manually toggled to change order) - in the future when we implement reordering, we will need to actually follow the z-order
* still assigned late or incorrectly at times - but using same detection logic as previously
876449f
to
d264d55
Compare
Doing more testing this morning, I found a bug in Specviz. The layer icon for a subset only appears after you make another subset, rather than when the first is finalized: Screen.Recording.2024-10-21.at.8.42.56.AM.mov |
Never mind, that was a known issue. That's what I get for reviewing in the morning without re-reading the original description! |
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 ok to me, modulo the known issues to be handled in follow ups.
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 looks good to go. Thanks!
Description
This pull request generalizes the existing stylized layer icons used for layer tabs in plot options to also be used in the viewer layer legends (which will eventually be used to open the new data-menu).
TODO:
Known "delayed update" issues hopefully fixed by upstream subset messaging work:
Change log entry
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, maintainershould 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.
trivial
label.