Improve Annotations vs Glyphs for 3.0
See original GitHub issueThere are duplications, inconsistencies and warts around annotations.
Some context: The original motivation for splitting off annotations like BoxAnnotation
from say, a Rect
glyph is that annotations may be positioned via screen coordinates, which makes re-using the spatial index hit-testing cumbersome/impossible.
Some goals:
-
Adopt consistent naming conventions for single/multiple. E.g. we have
Label
(single) andLabelSet
(plural) for labels. But Arrow i implicitly vectorized with a source. -
Allow annotations to be added to legends (this has come up several times recently)
-
Allow annotations to participate in hit testing – but this is probably best exposed as a new event for annotations, rather than selections on data sources
-
Some annotation specific improvements:
- make it easy to attach labels to other things
- make arrows simpler/easier to use (also easy to “attach” to things)
-
Try to find opportunities to reduce code duplication between annotations and similar glyphs
EDIT:
- Allow annotation visibility to be linked to other glyphs
cc @bokeh/dev What else?
Issue Analytics
- State:
- Created 3 years ago
- Comments:17 (15 by maintainers)
Top GitHub Comments
I think it’s reasonable to have separate types for glyph labels and plot labels. Indeed there would have to be, if we make the
PlotAnnotation
vsGlyphAnnotation
split in the class hierarchy. I just don’t like the current names “Label” and (especially) “LableSet” at all.So, FYI I agre things should be made less obtrusive, think there are reasonable reasons to maintain some separation:
annotation should generally go “on top” so the separation affords a place to specify an appropriate default render level for annotations that is different from glyphs
rbush spatial indexing uses data coords. It has to, otherwise a complete-reindex would be required on e.g. every single pan movement. But this makes hit testing things that can have fixed screen coordinates (or worse–a mix of screen and data coordinates) very, very difficult.
What would like is for annotations to support hit tests, just not to use rbush for it like glyphs do (there are usually only a relatively small number of annotations drawn, hit testing can just be brute-forced in screen space)
We also jut have a lot of glyphs. Keeping a group of “annotations” affords some structure for documentation, even if things can be used relatively in the same manner.
Also there are thing that just behave differently. There is no glyph analogue to
Band
, and I don’t think there should be. There is no notion of rects or quads that can be unbounded in any dimension, and I don’t think there should be that, either.