plugin API hints

[kecnry]

Description

This pull request implements the infrastructure for in-UI plugin API hints, as well as implementing the hints for a number of (but not all) plugins.

Screen.Recording.2024-08-07.at.9.20.57.AM.mov

The diff is large, but mostly boilerplate. The basic concept is:

• a button in the plugin template that toggles api_hints_enabled traitlet (also available to toggle from the API). This button is added when jdaviz is running in a notebook and the following properties are all passed to j-tray-plugin: config and plugin_key (used to show the line for accessing the plugins from config.plugins[...]), as well as :api_hints_enabled.sync.
• any UI element can opt-in to reacting to api_hints_enabled to change the label. In some cases this is done by passing api_hint and :api_hints_enabled='api_hints_enabled' to a re-usable component, and in other cases its done directly inline with :label='api_hints_enabled ? 'plg.whatever = ' : 'Normal Label'. When manually changing the label/content, the api-hint class should also be added (re-usable components do this for you).
• use the api-hint CSS class to style API hints in orange, monospace text to differentiate them from other labels.

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? Set this to bugfix milestone if this is a bug fix and needs to be released ASAP; otherwise, set this to the next major release milestone. Bugfix milestone also needs an accompanying backport label.
• After merge, any internal documentations need updating (e.g., JIRA, Innerspace)?

[codecov]

Codecov Report

Attention: Patch coverage is 88.88889% with 1 line in your changes missing coverage. Please review.

Project coverage is 88.83%. Comparing base (f8cd410) to head (4b19f18).
Report is 136 commits behind head on main.

Files with missing lines	Patch %	Lines
...nfigs/default/plugins/plot_options/plot_options.py	50.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3137      +/-   ##
==========================================
- Coverage   88.83%   88.83%   -0.01%     
==========================================
  Files         112      112              
  Lines       17430    17436       +6     
==========================================
+ Hits        15484    15489       +5     
- Misses       1946     1947       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[gibsongreen]

I think this will be an awesome addition, especially for new users!

The only thing in testing in the UI that I thought could be improved were the button hints. When you're in the normal UI, it's clear what a hint or title is versus the button. When you're using the API hints, all the hints, including the button hint, are in the same or similar color. It threw me off for a moment that you could still click the API hint button. The background of the button still does change color when you hover.

I don't know if it'd be better to distinguish the button with a different color when the API hints are active, or if the API hint can go under the normal button.

---

---

I'll continue messing around with it this afternoon and see if anything pops out at me in the code, reiterating this butI think this is really awesome and will be super helpful for users.

[kecnry]

It threw me off for a moment that you could still click the API hint button. The background of the button still does change color when you hover.

I don't know if it'd be better to distinguish the button with a different color when the API hints are active, or if the API hint can go under the normal button.

Good ideas - I'll give both of those a try next week and we can see how they look. We likely will want to send this to @Jenneh when she's back as well and iterate further on the style as we hear feedback from her and users. For now I was mainly focused on making sure all the different types of input had support and there was some consistent styling to make the API hints standout from everything else.

[javerbukh]

The code seems really well done and from my testing everything works as expected, nice job! I think this would benefit from some stress testing during a hack hour and maybe a crash course from you on implementing plugins with these features, but as the work stands it looks good to merge!

[gibsongreen]

Did a second pass on testing and looking through the code, everything checks out!