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

Annotation viewer components #278

Open
wants to merge 152 commits into
base: main
Choose a base branch
from
Open

Annotation viewer components #278

wants to merge 152 commits into from

Conversation

hudson-newey
Copy link
Member

@hudson-newey hudson-newey commented Jan 22, 2025

Annotation viewer components

Changes

  • Adds oe-annotate, oe-annotation, and oe-tag components
  • Adds error/warning messages if the user inputs an incorrect value to an enum restricted attribute
  • Removes the (currently broken) "results" dropdown from the doc site examples (this was present because downloading results didn't exist)
  • Removes erroneous TypeScript use of as const on component event name declarations

Related 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 mixin
Fixes: #153 needed to migrate axes to chromeProvider mixin
Fixes: #282 needed for spectrogram-top attribute
Fixes: #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 now
Fixes: #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

  • If we want to display annotations in the verification grid, we will need to spec out some new properties that will be required and add it to the default grid tile template

Visual changes

image

CSS parts warning on doc site "components" page

Final Checklist

  • All commits messages are semver compliant
  • Added relevant unit tests for new functionality
  • Updated existing unit tests to reflect changes
  • Code style is consistent with the project guidelines
  • Documentation is updated to reflect the changes (if applicable)
  • Link issues related to the PR
  • Assign labels if you have permission
  • Assign reviewers if you have permission
  • Ensure that CI is passing
  • Ensure that pnpm lint runs without any errors
  • Ensure that pnpm test runs without any errors

@hudson-newey hudson-newey added enhancement New feature or request ui labels Jan 22, 2025
@hudson-newey hudson-newey self-assigned this Jan 22, 2025
Copy link

github-actions bot commented Jan 22, 2025

Copy link
Contributor

@atruskie atruskie left a 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.

@@ -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];
Copy link
Contributor

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

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks for catching that. Updated code is below

image

Comment on lines 66 to 68
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.
Copy link
Contributor

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

Copy link
Member Author

@hudson-newey hudson-newey Feb 5, 2025

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

@@ -115,6 +115,15 @@ export class UnitConverter {
this.inverseLinearScale(this.frequencyDomain.value, this.frequencyRange.value, this.frequencyInterpolator.value),
);

public annotationRect(): Rect<Pixel> {
Copy link
Contributor

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?

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 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 the DOMRect standard
  • DOMRect has some additional properties beyond x (left), y (top), width, and height (see image below)

image

@hudson-newey hudson-newey marked this pull request as ready for review February 6, 2025 04:40
@hudson-newey hudson-newey changed the title [DRAFT] Annotation viewer components Annotation viewer components Feb 25, 2025
Copy link
Contributor

@atruskie atruskie left a comment

Choose a reason for hiding this comment

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

generally: i wonder if we should be namespacing our event names

you've got a few tests missing, but otherwise looks great

it looks like a lot of the snapshots changed....
image why? - discussed offline. But update test container to a useful height, e.g. 512px.

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment