Attach select menus

[duytnguyendtn]

Description

Historically, we've always had an issue with dropdown menus floating around when the user scrolls the notebook. When working on #1656, I found an attach property that effectively docks the dropdown menu to the v-select:

Before:

ImvizExample.-.Jupyter.Notebook.-.Brave.2022-09-22.17-27-37.mp4

After:

ImvizExample.-.Jupyter.Notebook.-.Brave.2022-09-22.17-25-25.mp4

The only consequence that we have to consider here is entries whose names are larger than the plugin bar. Before, the floating menu could accommodate any sized item by overflowing:

When the menu is attached, the menu is restricted to the size of the v-select:

Ideally, we could combine the two, attach the menu and allow the overflow, but I haven't found how to do that. I've created this PR as a POC, and to encourage discussion on how we can handle this side-effect

Change log entry

• Is a change log needed? If yes, is it added to 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, maintainer
  should 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.

• Are two approvals required? Branch protection rule does not check for the second approval. If a second approval is not necessary, please apply the trivial label.
• Do the proposed changes actually accomplish desired goals? Also manually run the affected example notebooks, if necessary.
• Do the proposed changes follow the STScI Style Guides?
• Are tests added/updated as required? If so, do they follow the STScI Style Guides?
• Are docs added/updated as required? If so, do they follow the STScI Style Guides?
• Did the CI pass? If not, are the failures related?
• Is a milestone set?
• After merge, any internal documentations need updating (e.g., JIRA, Innerspace)?

[codecov]

Codecov Report

Base: 87.11% // Head: 87.12% // Increases project coverage by +0.00% 🎉

Coverage data is based on head (3cc123a) compared to base (9f3bd13).
Patch has no changes to coverable lines.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1673   +/-   ##
=======================================
  Coverage   87.11%   87.12%           
=======================================
  Files          95       95           
  Lines        9887     9894    +7     
=======================================
+ Hits         8613     8620    +7     
  Misses       1274     1274           

Impacted Files	Coverage Δ
...nfigs/imviz/plugins/links_control/links_control.py	100.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[kecnry]

Now that #1656 is in, can this be rebased and see if the behavior conflicts with the alignment changed there (see #1656 (comment))?

[rosteen]

@duytnguyendtn Looks like this needs a pretty big rebase, I'll hold on testing until you resolve that.

(edit: actually looks pretty simple, just the same thing in a lot of files)

[duytnguyendtn]

Thanks for the rebase pings @rosteen and @kecnry! Should be fixed

[duytnguyendtn]

FWIW I looked into @javerbukh's hover suggestion and I couldn't figure out how to do it, though the internet suggested it should be easy 😅 @kecnry maybe you know how?

[kecnry]

General thoughts on the issue with text extending beyond the width and truncating:

• the advantages of the attached menu might be worth the disadvantages of truncated text
• the user can always make the panel wider to see something that is truncated
• we can get rid of “Common” in "Common Galactic" to minimize friction in known cases (obviously data labels are somewhat out of our control)
• implementing tooltips or wrapping within the menus is possible, but that should be done as a reusable component and would take some effort. For tooltips, we'd likely only want to have tooltips created on-the-fly for entries that are likely to overflow, otherwise I think it would be quite annoying for the user.

[rosteen]

Looks good to me, did a quick grep and couldn't find any that you missed. I think the advantages outweigh the occasional truncation at small browser widths - in lab I actually couldn't find any cases that were truncated, the list names all fit. Users can always expand the panel a bit.

[pllim]

Yikes, there is a conflict now. Please rebase.

[duytnguyendtn]

Thanks for the heads up @pllim! I think I fixed it

[kecnry]

Ok, I agree - let's get this in and we can always improve any truncation cases as needed later. I'd still be in favor of getting rid of "Common" since that is the most common (hehe) case of overflow that might be confusing, but we can defer that until later as well, if you'd rather.

[pllim]

This is technically a bug fix, so I think it needs a change log. If this has been annoying someone, they would be happy to see it in the change log as fixed.

[pllim]

As for side effects of "attaching" very long list, maybe we can open a separate issue for that.

[pllim]

LGTM. Thanks!

[duytnguyendtn]

The rare triple approval! Thanks @pllim @rosteen @kecnry for the eyes; will merge once I get the green checks!