-
Notifications
You must be signed in to change notification settings - Fork 0
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
Annotation viewer components #278
base: main
Are you sure you want to change the base?
Conversation
8bd32b8
to
491e712
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.
Generally not keen on using the term heading for annotation labels. You may have used a h
element, but they're not actually headings for paragraphs.
have we considered using lit context for the chrome advertisement?
there are a bunch of snapshots that are just black - no box rendered. double check validity?
So i'd really like to see chrome components not have to extend and implement interfaces.
...ion-overflowing-annotations-corner-21577-ld-position-correctly-in-the-top-right-corner-1.png
Outdated
Show resolved
Hide resolved
...ion-overflowing-annotations-partia-9b6b8-tly-if-only-the-high-frequency-has-overflowed-1.png
Outdated
Show resolved
Hide resolved
...ion-overflowing-annotations-fully--f24c8-f-it-has-fully-overflowed-the-negative-y-axis-1.png
Outdated
Show resolved
Hide resolved
...ion-overflowing-annotations-fully--8fb0b-f-it-has-fully-overflowed-the-negative-x-axis-1.png
Outdated
Show resolved
Hide resolved
src/components/annotate/annotate.ts
Outdated
@@ -191,8 +163,8 @@ export class AnnotateComponent extends ChromeProvider(LitElement) implements Wit | |||
// math so that we only have to do one calculation | |||
// | |||
// TODO: we might want to make this inclusive e.g. >= | |||
const isTimeInView = model.startOffset < temporalDomain[1] && model.endOffset > temporalDomain[0]; | |||
const isFrequencyInView = model.lowFrequency < frequencyDomain[1] && model.highFrequency > frequencyDomain[0]; | |||
const isTimeInView = model.startOffset > temporalDomain[0] && model.endOffset >= temporalDomain[1]; |
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.
you've mixed up the domain indices here
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.
When the annotation headings are positioned at the top of the spectrogram | ||
(tag-style="spectrogram-top"), if the label is too large to fit inside the | ||
annotations width, it can cause the heading to overflow and not be visible. | ||
if the label is too large to fit inside the annotations width, it can | ||
cause the heading to overflow and not be visible. |
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.
even with the change i'm still confused by this comment.
do you mean:
a) in mode spectrogram-top (then why are we talking about that in .style-edge?)
or b) in mode edge, but when an annotation is rendered right at the top of the spectrogram
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 talking about option b in your example
If you're still confused by it, I definitely need to change the wording of the comment
src/models/unitConverters.ts
Outdated
@@ -115,6 +115,15 @@ export class UnitConverter { | |||
this.inverseLinearScale(this.frequencyDomain.value, this.frequencyRange.value, this.frequencyInterpolator.value), | |||
); | |||
|
|||
public annotationRect(): Rect<Pixel> { |
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 it worth reusing DOMRect?
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 a couple of reasons for not using DOMRect
- We have have generic type hints (unfortunately not type checking) for a
Rect<Pixel>
- The DOMRect is defined externally by the tc39 group and the TypeScript team, meaning that if we update TypeScript, DOMRect might change. This would sometimes be a benefit, but in this case, the
Rect
is not strongly dependent on the shape of theDOMRect
standard - DOMRect has some additional properties beyond x (left), y (top), width, and height (see image below)
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.
a05c7a0
to
c984588
Compare
This commit also improves the performance of the annotate component because the component no longer performance an update loop whenever the component resizes. spectrogram-top tag style positioning can be dynamically updated using signals from the unit converter.
Now if you change an oe-annotations attribute (e.g. start-time) it will update in the annotation viewer component
"In case of ~~fire~~ cyclone: 1. git add 2. git push" This commit improves JS annotation label positioning and fully removes non-functional anchor positioning.
Annotation viewer components
Changes
oe-annotate
,oe-annotation
, andoe-tag
componentsas const
on component event name declarationsRelated Issues
Fixes: #5 "Annotation Viewer Component"
Fixes: #279 "Allow templating components in any order"
Bugs fixed during refactoring
Fixes: #255 needed to migrate axes to
chromeProvider
mixinFixes: #153 needed to migrate axes to
chromeProvider
mixinFixes: #282 needed for
spectrogram-top
attributeFixes: #78 needed to fix surface sizing
Fixes: #90 needed to fix zero width collapse
Fixes: #281 A bug I thought I created during the spectrogram
chromeHost
migration, but turns out it was a long standing bug that I never noticed until nowFixes: #100 in hind sight, this was not needed. I originally thought it was needed because (long story short) reactivity was broken within the axes component. But I'm not going to revert a bug fix
Fixes: "Axes component used overflow rendering for labels"
Fixes: "Removing axis title / labels doesn't shrink chrome"
Fixes: "Box model for media-controls host is incorrect"
Fixes: "Standalone indicator component can't shrink if not inside container"
Fixes: "Bug in spectrogram.spec.ts" snapshot tests where the spectrogram would not obey the min-height
Fixes: "Fixes a bug where the enum attribute converter would throw an error for
null
(empty values e.g.<oe-annotate tag-style></oe-annotate>
)"Fixes: "Bug where the spectrogram host element would not respect the spectrograms
min-height
(this could cause the canvas to overflow the spectrogram host element)"Tasks not resolved by PR
Visual changes
CSS parts warning on doc site "components" page
Final Checklist
pnpm lint
runs without any errorspnpm test
runs without any errors