Widen history panel entity picker

[karwosts]

Proposed change

The current history panel entity picker gets several complaints for being too narrow. It is by default around 230 pixels, and any medium to long entity names get cut off and are hard to distinguish.
Also, at around 900 pixels in width the whole picker squishes up against the right side and is cut in half.

Current behavior:

This change tweaks the wrapping behavior in the history panel, and tries to fix the entity picker at 400 pixels, which aligns nicely width the width of the 3 picker chips, and should allow for seeing much more of entity names. And it lets the whole picker wrap more instead of squishing up against the right edge.

Proposed behavior:

ha-target-pickers instanced by ha-selector-targets on other panels are unchanged, they don't seem to have this problem.

Area and Devices picker are unchanged, their names are not nearly as long, so don't seem to have this problem.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (thank you!)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Example configuration

Additional information

• This PR fixes or closes issue:
  fixes Dropdown box does not show entire entity name #13671
  fixes choose entity drop down too narrow #14897

• This PR is related to issue or discussion:
  History - Choose (Area|Device|Entity) drop down search box width too small #13648
  https://community.home-assistant.io/t/increase-the-width-of-the-search-bar-on-new-history-browser/437439

• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• There is no commented out code in this PR.
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

[ildar170975]

@karwosts
Thank you very much!
Will this solution work properly on mobile clients with different orientations?

[karwosts]

Will this solution work properly on mobile clients with different orientations?

I don't have a mobile connected to my dev environment, but based on my understanding I would assume so? I don't think there's any special "mobile" renderer, it's all just treated like rendering a webpage regardless of client. I can put the chrome browser to mimic the dimensions of certain mobiles, like for example here is Pixel 5, vertically and horizontally.

Looks like most mobiles have a width of <400 pixels, so I believe it will just fill the whole width as best as possible in the vertical mode.

[ildar170975]

What do you think about filling a whole width in both portrait and landscape modes?
Imho the same will be good for a desktop too. Cannot test it myself, do not have a dev test setup(((

[karwosts]

What do you think about filling a whole width in both portrait and landscape modes?

I think in my opinion a maximum cap on the width is appropriate. Otherwise you have someone with a large 4k monitor gets a dropdown box that's 2 feet wide... seems a bit absurd to me.

[ildar170975]

Or may be this variant:

1. If a viewport’s width > some_value:
   — place the field on the same line as selectors for “entity_id”, “device”, “area”;
   — make the field’s width to fit all available (remained) width.
2. Otherwise:
   — place the field on the next line;
   — make the field’s width to fit all available width (I.e. full width).

?

[karwosts]

No, I think unfortunately that still has the same concern for me. Anytime you have "... and then fill all remaining width", it means someone will have a 3000 pixel wide entity picker, which I don't think is correct.

I'm happy with the current behavior. If you think there is a specific deficiency with the implementation, please raise it, but otherwise I will await further comments or Member review.

[ildar170975]

I think your implementation is anyway very useful, will be happy to get it)))).
Further improvements may be proposed after practical testing.

[bramkragten]

Do you agree this might be a better solution?

CleanShot.2023-01-03.at.12.12.13.mp4

[bramkragten]

#14970

[karwosts]

Closing as obsolete