[Bug][6.6.2] Accordion height for pre "is-active" accordion item not correct

Expected Behavior

In previous versions (<6.6.2) the accordion works as expected.
We have a nested accordion where the first level is always closed but the second level gets an "is-active" css class at the accordion-item (on page load)  if the user has some filter previously activated. Before the upgrade to 6.6.2 if we open the first level accordion the second level was opened as expected but now the height and elements in the second level are broken.
6.6.2 with "is-active" on page load:

6.6.2 for all additional accordion items which has not set the is-active class on page load.

All versions before 6.6.2 shows our accordion correctly like the second case above. (Opened and correctly calculated height)
If i downgrade to 6.6.1 / 6.6.0 / 6.5.3 our accordion is working normal.
Current Behavior

The height is not correctly if the "is-active" class is set before the page is rendered.
The accordion looks broken.
Possible Solution

Currently i dont know how to fix it (expect to downgrade the version)
Test Case and/or Steps to Reproduce (for bugs)

Test Case: https://codepen.io/DarkStaRX/pen/VwvZBGx
I set the css class "is-active" above the headline "Test 1.1"
If you open the first accordion you will see height problems with the first (currently active) accordion. this just happens if you set the is-active class on the element by yourself. all other accordions working correctly.

How to reproduce:

Create a new accordion
Create a new nested accordion in the first one.
Set the active class on the first nested accordion.
Create a addition nested accordion below the active accordion
see the result ist broken for the active accordion

Context

Nested accordions to provide links for different categories. Working currently on production in a lower version of foundation.
Your Environment

Foundation version(s) used: 6.6.2
Browser(s) name and version(s):  Chrome 80.0.3987.163
Device, Operating System and version: Windows 10 1809 (OS Build 17763.973)
Link to your project: Private Repository

Checklist

[x] I have read and follow the CONTRIBUTING.md document.
[x] This is a bug report or a feature request.
[x] There are no other issues similar to this one.
[x] The issue title and template are correctly filled.

Hi @D4rkiii,
thanks for reporting this.
We will check this.

Ok, I did a git bisect using git bisect start && git bisect bad v6.6.2 && git bisect good v6.6.1.
As I feares, a bugfix introduced this regression.
777baa81ede36d672b5369f9888e00f274c3ebc7 is the first bad commit
commit 777baa81ede36d672b5369f9888e00f274c3ebc7
Author: Daniel Ruf<EMAIL_ADDRESS>Date:   Mon Oct 14 23:39:44 2019 +0200

    fix: clear the animation queue - closes #10486

 js/foundation.accordion.js | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

See https://github.com/foundation/foundation-sites/issues/10486

It seems we need finish() here. I will create a PR to fix this.

Would be great if you could test this too @D4rkiii.
I tested it locally and this fixes the old issue and this one.

You should be able to verify this by also patching the latest release file manually.


update compile output to a complete spec

What type of PR is this?

/kind feature
What this PR does / why we need it:
update compile output to a complete spec
Which issue(s) this PR fixes:

Fixes #410
Special notes for your reviewer:
Does this PR introduce a user-facing change?

Update compile result form Spec.resource to a complete Spec

Additional documentation e.g., design docs, usage docs, etc.:

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
4 unchanged lines in 2 files lost coverage.
Overall coverage increased (+0.07%) to 72.55%

Files with Coverage Reduction
New Missed Lines
%

pkg/engine/operation/watch.go
1
85.93%

pkg/engine/operation/parser/parser.go
3
78.21%

Totals

Change from base Build<PHONE_NUMBER>:
0.07%

Covered Lines:
5109

Relevant Lines:
7042

💛  - Coveralls


Hide some entities by default

Is your feature request related to a problem? Please describe.
The Frigate integration provides lots of entities, so that we can automate everything we want. But, I noticed that some entities aren't exactly "user friendly" (not sure if it's the right way to call it or not), but instead only "automation friendly".
Some examples are:

Object specific camera entities (not the main cameras)
Switch entities (to turn off snapshots, recordings, etc)
The binary sensors for motion detection (maybe)
The number sensors for object counts
The sensors related to diagnostics

And the problem that arises because of it is:

Auto-generated dashboards include them all
My Google Assistant integration recognizes them all, but this was never meant to be, I don't want to be able to voice-control all these little entities (neither I want my Google Home dashboard cluttered by them).

Describe the solution you'd like
This is exactly what HA 2022.4 tried to solve by bringing the Hidden entities feature:

they are no longer shown on auto-generated Dashboards; they are automatically hidden from HomeKit, Alexa & Google Assistant and aren’t called when a service call targets their area.

I believe everything but the main cameras (this is debatable of course) could be hidden by default.
Describe alternatives you've considered
To hide them all myself. It's very hard though (in my installation, Frigate integration provides 339 entities).
Additional context
I would be happy to hear opinions about it.

This seems like a good idea to me. A blunter instrument would be to disable them (some of the new entities were added disabled by default in this same spirit).
A principled stance would be best, i.e. lets take the entities per camera and break them into 3 categories (enabled by default, hidden by default, disabled by default) -- and agree on those 3 categories first.

Yeah I am a fan of the principled stance, either way might be good to create a doc explaining the reasoning between the different categories and where the entity goes so future contributors have an idea and we have something to reference as well.

Enabled by default
Principle
Anything required for usecases of the integration or card to provide an excellent "out of the box" experience when that usecase is likely applicable to the majority (>50%) of users of the TAM for the integration, or the card, individually.
Experience the user will have

Attribute
Enabled

Entity is active in the HA state machine (e.g. can be used in the card, automations, templates)
:heavy_check_mark:

Entity state is recorded
:heavy_check_mark:

Entity shows up on automatically generated dashboards
:heavy_check_mark:

Entity is included in 'area' targeted service calls.
:heavy_check_mark:

Entity is exposed to Homekit, Google Assistant & Alexa
:heavy_check_mark:

Hidden by default
Principle
Anything required for more niche/expert usecases for either the integration or card when that usecase is likely applicable to at least (25%) of the users of the TAM for the integration, or the card, individually.
Experience the user will have

Attribute
Enabled

Entity is active in the HA state machine (e.g. can be used in the card, automations, templates)
:heavy_check_mark:

Entity state is recorded
:heavy_check_mark:

Entity shows up on automatically generated dashboards
:heavy_multiplication_x:

Entity is included in 'area' targeted service calls.
:heavy_multiplication_x:

Entity is exposed to Homekit, Google Assistant & Alexa
:heavy_multiplication_x:

Disabled by default
Principle
Anything where the likely usage is < 25% of the TAM for either the integration or card.
Experience the user will have

Attribute
Enabled

Entity is active in the HA state machine (e.g. can be used in the card, automations, templates)
:heavy_multiplication_x:

Entity state is recorded
:heavy_multiplication_x:

Entity shows up on automatically generated dashboards
:heavy_multiplication_x:

Entity is included in 'area' targeted service calls.
:heavy_multiplication_x:

Entity is exposed to Homekit, Google Assistant & Alexa
:heavy_multiplication_x:

Example assignment of entities to categories
Summary

Category
Icon
Count today
Count with below proposal

Enabled
:heavy_check_mark:
11
6

Hidden
:eye:
0
6

Disabled
:heavy_multiplication_x:
4
5

Entity unique_id suffix
Description
Note
Current Category
Proposed Category

camera:[camera]
The main Frigate camera stream

:heavy_check_mark:
:heavy_check_mark:

camera_snapshots:[camera]_[object]
The object specific camera snapshot

:heavy_check_mark:
:eye:

motion_sensor:[camera]_motion
The motion detection for the camera
Used via websocket for the default card configuration when no object is specified
:heavy_multiplication_x:
:heavy_check_mark:

occupancy_sensor:[camera/zone]_[object]
The occupancy sensor for the object within the camera/zone

:heavy_check_mark:
:heavy_check_mark:

occupancy_sensor:[camera/zone]_all
The occupancy sensor for all objects within the camera/zone
Used via websocket by the default card configuration when no object is specified
:heavy_multiplication_x:
:eye:

sensor_detector_speed:[detector]
The detector speed for CPU/coral

:heavy_check_mark:
:heavy_multiplication_x:

sensor_fps:[camera/detection/process/skipped]
FPS diagnostic sensors

:heavy_check_mark:
:heavy_multiplication_x:

sensor_fps:detection
Overall Frigate detection speed

:heavy_check_mark:
:heavy_multiplication_x:

sensor_object_count:[camera]_[object]
Object count for that object

:heavy_check_mark:
:heavy_check_mark:

sensor_object_count:[camera]_all
Object count for all objects

:heavy_multiplication_x:
:eye:

switch:[camera]_detect
Camera detect setting

:heavy_check_mark:
:eye:

switch:[camera]_motion
Camera motion setting

:heavy_multiplication_x:
:eye:

switch:[camera]_recordings
Camera recording setting

:heavy_check_mark:
:heavy_check_mark:

switch:[camera]_snapshots
Camera snapshots setting

:heavy_check_mark:
:heavy_check_mark:

switch:[camera]_improve_contrast
Camera improve contrast setting

:heavy_multiplication_x:
:heavy_multiplication_x:

update:frigate_server
Whether there's a Frigate update available

:heavy_check_mark:
:eye:

Caveats
Above heavily based on my own usecases. Adding some integration/card contributors for feedback on how the above matches their usecases: @NickM-27 , @felipecrs , @blakeblackshear , @peledzius , @drinfernoo

Wow that's very comprehensive! Overall I agree, seems reasonable to me 👍

I believe I would hide the following entities as well:

motion_sensor:[camera]_motion
occupancy_sensor:[camera/zone]_[object]
sensor_object_count:[camera]_[object]
switch:[camera]_recordings
switch:[camera]_snapshots

Impressive summary!
I believe I would hide the following entities as well:

motion_sensor:[camera]_motion
occupancy_sensor:[camera/zone]_[object]
sensor_object_count:[camera]_[object]
switch:[camera]_recordings
switch:[camera]_snapshots

Personally, I feel like over 25% of users would use most of these. sensor_object_count:[camera]_[object] I can see probably less likely and makes sense to hide.
But with all those hidden the only thing not hidden by default is the camera view itself which to me makes less sense / too much the other way compared to what it is now, just my 2c though.

Agree with Nick, suspect most of these are >25%. Moved sensor_object_count:[camera]_[object] to hidden, as perhaps that's the weakest one.

Going to leave this open, as I temporarily avoided the use of hidden entities pending resolution of a Home Assistant frontend bug. More details in the PR: https://github.com/blakeblackshear/frigate-hass-integration/pull/273
Leaving this bug open for now.

Hi,
Just leaving a quick feedback about the default inclusion of all_occupancy binary sensors (per camera and, per zone)
I just disabled all of them because it creates lots a redundant logs with  [object]_occupancy.
I think they are not very relevant by default since my guess is the users usually want to target a specific kind of occupancy.
Is a person there? Is a car there?
The case of mixing objects seem less relevant. Are the dog or a person in the living room ?... Is the front camera detecting a person or a car?... Ok maybe but I would explictely look for each object count in that case.

Hi,
Just leaving a quick feedback about the default inclusion of all_occupancy binary sensors (per camera and, per zone)
I just disabled all of them because it creates lots a redundant logs with  object_occupancy.
I think they are not very relevant by default since my guess is the users usually want to target a specific kind of occupancy.
Is a person there? Is a car there?
The case of mixing objects seem less relevant. Are the dog or a person in the living room ?... Is the front camera detecting a person or a car?... Ok maybe but I would explictely look for each object count in that case.

@Mincka Background: The all_occupancy is default enabled mostly so that the card has a default way of getting "an occupancy sensor" without the user need to explicitly configure anything (if all_occupancy was disabled, the card would require the user to tell it which object to pay attention to the occupancy for). It wouldn't be terrible, but it would be slightly less 'magic' than if we can mostly count on the all_occupancy sensor being enabled...

Thanks for the explanation. I understand your point even it's a choice for the integration based on the card that people may not use at all. Anyway, it's only a matter of a few seconds to disable them. Also, disabling them by default makes them more difficult to discover in HA.

One may claim they should be hidden, though. Which I have no opinion on.

I think we'd love to have it hidden, too bad HA frontend behavior / bug means hidden is not an option currently

Oh yeah, I forgot it.

Can this issue be reopened while we wait for https://github.com/home-assistant/frontend/issues/12887?

The Home Assistant fix appears to be back now 😄


Meteor1 3

Works as far as I can see... definitely could use some more banging on. No attempt to take advantage of new es2015 module support and testing yet.

Because meteor 1.3 uses node v0.10.45, to get outgoing http requests to no freak out over odd characters in http headers (which happens a lot), you have to set:
export NODE_OPTIONS="--security-revert=CVE-2016-2216"
More details here:
https://nodejs.org/en/blog/vulnerability/february-2016-security-releases/


yesod-minimal template doesn't support running with stack exec -- yesod devel

it's a bit too minimal
probs should at least let it do this.

This is documented on the Yesod quickstart page:

Also, if you choose the "mini" scaffolding, yesod devel will not work.

i suppose so; but maybe it could have a very simple devel entrypoint? or do you consider that outside the scope?

It's outside the scope, it will make the template more complicated than
desired.
On Tue, Apr 19, 2016 at 1:03 PM, Noon van der Silk<EMAIL_ADDRESS>
wrote:

i suppose so; but maybe it could have a very simple devel entrypoint? or
do you consider that outside the scope?
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/commercialhaskell/stack-templates/issues/60#issuecomment-211837228

okay


Feature/38 create readme md for foundation

Readme file updated with detailed installation instructions.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Adding a second volume seems to duplicate the first one

Starting the VolumeRenderDemo and adding a new volume (using the T1 head) adds a blurry (?!) version of the first volume and slows down my machine drastically.

Not sure if it is a second volume. But there is defnitly something wrong with visibilty. I can only hide all or none of the volumes by setting all volumes to visible. As long as one volume is set to visibible all volumes are visible.

@moreApi that sounds different, this bug is:
Run mesh demo: see the cube volume
Add T1 head: another cube is added to the scene and there is no head.

Then I cant repoduce the bug. For me the head is added but it is hidden by a very small scale and transparent transfer function. But that is expected behavior in my experience.

@moreApi you are very correct. I now understand why the visibility part is the main issue here.
If you delete the cube volume, then you can see the T1 head without doing anything with visibility.

should be solved by https://github.com/scenerygraphics/scenery/pull/544

This was closed by updates for scenery 0.9.0. I tested on commit d50e2a8e920ace13b09dd0ed9e4f02646d8dd443


Seller Terminal- Category management - Test

basic functions look ok . passed on for testing - In Test.

hello sir,
I am done with the task based on php
php.zip


PIP-843: Dedicated publishes in tk-multi-publish2 to export scene data to various file formats

Primary Changes:

Added support for exporting camera, camera_tracks, object_tracks & geometry to .abc, .fbx, .ma, .nk & .usda.
-- camera: Only camera
-- camera_track: Only tracks corresponding to respective camera
-- object_track: Geometry and tracks of the respective object
-- geometry: Entire static geometry of the scene
-- NOTE: Depending on the exporter used, sometimes the exported items will be parented to another empty root node. Additionally, some files may contain data that was not filtered out entirely.
When creating a new file via the tk-multi-workfiles2 app, the file selection-popup automatically defaults to the Footage folder of the selected shot/asset/element. If the folder does not exist, the root directory of the project is selected.

Testing:

Start SynthEyes via ShotGrid
Open a saved file or create a new file and save it via the SynthEyes ShotGrid Panel.
Click on Publish in the SynthEyes ShotGrid Panel
Select the desired exports in the publisher:

Check the project folder to verify that SynthEyes exported the files correctly.

Required Repository:

tk-config-lavapipeline
-- https://github.com/lavalmi/tk-config-lavapipeline/pull/135

Testing environment:

Configuration: matchmove-dev (see PR above)
SynthEyes Pro 2024 Build 1057 64-bit installed at "C:\Program Files\BorisFX\SynthEyes 2024\SynthEyes64.exe"
Default port range from 59200-59300
Shotgun python version: 3.7.11

Changes have been made to accommodate scenarios where either no SynthEyes sticky folder exists or the corresponding sticky file is not present. The folder is now simply created if needed and the sticky file is no longer expected to be in that path at all times (as it should be).


Do not call reset() in Table code

Now it's needed in Table.headers. For loaders.Web it means initiating a new http connection to reset a stream.
But after some Iterator improvement we'll be able to avoid it?

DONE


Setting Deployment.yaml annotations

How to set up annotations for deployment manifest. I have tried configuring IResourceBuilder.WithAnnotation() in my AppHost but that does not seems to work.
Base on this template it should be possible to configure it:
https://github.com/prom3theu5/aspirational-manifests/blob/4ea316499c352bf588532b16020f363c2dc4ff3e/src/Aspirate.Cli/Templates/deployment.hbs#L2-L13

It all depends on whats been output to the aspire manifest when its built by aspirate.
If aspire doesn't emit the annotations to the manifest then aspirate wont know about them
Do they appear in manifest.json?

Nope, they don't appear in the manifest.json, that does look like to be the issue.
Any chance you would know if IResourceBuilder<T>.WithAnnotation Method is the correct way to propagate annotation to manifest.json and then to deployment.yaml via Aspirate?
link to docs

I don't know a way unfortunately
You're likely going to have to use a patch strategy in kustomize to add them afterwards
The problem in they dont appear in the aspire manifest schema at all: https://json.schemastore.org/aspire-8.0.json

oh that's bummer, thanks anyway at least it make sense now 😄

Yw - I'll ping you back here if it ever gets added (will be post GA now for sure if it does - hopefully for 8.1) 😄

Hey, i was wondering the same thing. Are we able to manually add to the manifest.json and then generate the deployment.yamls with the annotations?

Hey, i was wondering the same thing. Are we able to manually add to the manifest.json and then generate the deployment.yamls with the annotations?

For anyone wondering, I was able to do this by adding annotations object under each resource in the manifest file after it was generated.
"annotations": {
        ...
      },

Then we can call aspirate generate -m ./manifest.json using the modified manifest file to generate deployments with the correct annotations.
Would be good if we have support for this


Remove Haptic template argument from sim::Bicycle

Handlebar feedback is independent of the bicycle simulation. The bicycle
simulation class should not compute handlebar feedback torque nor should
it have a handlebar object member variable.
Fixes #159

Originally, the bicycle simulation class was supposed to take a Haptic object so it would know how to calculate feedback torque.
That calculation has now been removed from the class.