New vars and cleanup for hover tooltips

[bryevdv]

A recent SO question asked about hover values for the actual tooltip "snap" locations. It seemed like this should be an easy add, but I was quickly reminded what an intolerable mess hover_tool.ts is. This PR adds those special vars and also attempts some minimal cleanup up that file. Not anywhere close to what is really needed, but a start. Goals for this PR:

• TooltipVars well-defined and typed and consistent for all cases
• Expose tooltip (x, y) and (sx, xy) as tt_x, tt_sy etc.
• Improve const-ness throughout
• Avoid redundant parameters in functions
• Simplify things where possible
• Expose the glyph object as a tooltip vac

I've left individual commits in case that is simpler to review. I tested with all the User Guide examples, but I do want/intend to create more examples that exercise a wider range of case. I have made a couple of explicit complexity trade-offs in a couple of places. I will note them with comments inline.

I would be interested in suggestions for:

• Any other TooltipVars we can add now
• Better names for tt_x, tt_sy, etc
• Adding (unit) tests
• Splitting up _update

For the latter I had thought possibly we could move the code for each case to the relevant glyph view classes, and we could do that. But, it would require passing a lot of parameters to the new methods.

I do plan to expand the relevant docs sections once the implementation work is completed.

Edit: follow-on question: This PR removes these oddball special vars from #11992

        const data_x = glyph._x
        const data_y1 = glyph._y1
        const data_y2 = glyph._y2

The can now be accessed in a CustomJSHover as e.g. special_vars.glyph._x etc. In fact anything on the glyph can now be easily used for a tooltip, which is great! But my question is, should the _x attrs etc . be made public?

Lastly, of course, the value is actually a glyph view, not a glyph. I've stayed consistent to the existing code for now, but should we tighten up the naming here at this point?

cc @mattpap @tcmetzger

cc @xaptronic for changes related to #11992

[bryevdv]

This is the "TODO" above, using sx and sy as in other cases. That said, I think glyph.get_anchor_point("center"...) will always return a value so maybe figure out a way to express that instead.

[mattpap]

If that's the case, then this information has to be encoded in get_anchor_point()'s type, i.e.:

get_anchor_point(anchor: "center", i: number, [sx, sy]: [number, number]): {x: number, y: number}
get_anchor_point(anchor: Anchor, i: number, [sx, sy]: [number, number]): {x: number, y: number} | null

get_anchor_point(anchor: Anchor, i: number, [sx, sy]: [number, number]): {x: number, y: number} | null {
  // implementation
}

[bryevdv]

I was too circumspect. It's not really the fact that it is center, per se. It is that, for the glyphs that happen to land on this codepath ("scatter-ish" more or less), the get_anchor_point always returns something for all values (including "center"). But that's not true for other kinds of glyphs, that don't take this codepath. So, I think it's a little more complicated. I can make an issue regarding cleaning up an making anchor point reporting more consistent everywhere, if you like.

[bryevdv]

The trade-off here was to reduce the number of params and simplify the calling in half a dozen other places (as well as avoid passing the same parameter essential twice)

[bryevdv]

Marking ready for initial technical review

[mattpap]

I was about to go ahead and merge this, but those imports need to be fixed first.

[bryevdv]

I was about to go ahead and merge this, but those imports need to be fixed first.

Hold up a bit, I will proceed to add more examples now

[xaptronic]

Sorry for my delayed reply here - I will aim to test my use-cases from #11992 with this branch. If you merge before I report back, I will open an issue/PR if there's an issue with the use cases. It sounds like if I can access the glyph from the tooltip, things should work out.

[bryevdv]

@tcmetzger I ended up changing to snap_x, snap_sy, etc on the rationale that it is the position that the tooltip snaps to (which may just be the cursor position, but may also be glyph "anchors" for glyphs that support that). LMK what you think.

[bryevdv]

@xaptronic note I also just changed the var name to glyph_view (since it is, in fact, a GlyphView. The inconsistency around glyph/glyphview was barely tolerable when it was internal but letting it escape to the wild is bridge to far)

[bryevdv]

@tcmetzger it looks like pydata sphinx theme 0.9 is out and breaks our prev/next layout customizations

[bryevdv]

@mattpap @tcmetzger I have fixed the theme breakage in 2c43494 I intend to merge this when green to unblock CI (other comments have been addressed, as noted)