-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace data annotations with glyphs #13344
base: branch-3.5
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## branch-3.5 #13344 +/- ##
==============================================
+ Coverage 91.57% 92.63% +1.05%
==============================================
Files 326 327 +1
Lines 20737 20787 +50
==============================================
+ Hits 18990 19255 +265
+ Misses 1747 1532 -215 |
I am 100% behind the migrating towards a glyph, but I really don't like "VWhisker" and "HWhisker". I'll have to think some on what the least disruptive path for users might be (or less awkward "V" and "H" names). |
Noting that https://discourse.bokeh.org/t/rotating-a-figure/10802 In that case |
406c044
to
cb01d0a
Compare
cb01d0a
to
9318ec0
Compare
I was able to provide a legacy implementation for We shouldn't make API design decisions (in this case whether there should be one or two band and whisker glyphs) based on our self imposed restriction of having a flat So my preliminary proposal is stop exposing new models via |
I thought we had alignment on the POV that "annotation is something a user does, not a particular kind of object" i.e. "making everything a glyph". So then having e.g. Regarding this:
The models exist for the implementation and our use as maintainers. The functions exist because users really hate having to import 30 things and want to do more with less code.. Having both really does not bother me at all, because they serve entirely different audiences with different purposes. |
f8557dc
to
108a14c
Compare
108a14c
to
19937f4
Compare
2b44ca0
to
ceda2a7
Compare
9126d7f
to
9e44da0
Compare
9e44da0
to
329a0cb
Compare
329a0cb
to
4a9b7a3
Compare
9d7d1ae
to
ae96e8c
Compare
Preliminary support coordinate systems that don't involve the frame (subcoordinates) has landed: Screencast.from.13.05.2024.17.35.54.webmOne missing bit is symbolic ranges to make to fully operational and to allow implementing screen coordinates in legacy APIs. |
ae96e8c
to
7b8ca2c
Compare
This is a proof of concept and a breaking change. This can be easily made into a non-breaking change by either naming the glyph differently or introducing two glyphs (
{H,V}Whisker
), similarly to what was done withSpan
annotation vs. span-like glyphs (PR #12677). The functionality is preserved except for screen units. Those can or will be possible to reproduce with sub-coordinates (a part of my current CZI work), though I'm not sure about usefulness of that. I also addedfigure().whisker()
for API completeness.addresses #9955