| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
I don't think this is 2.2.3 material, but others may disagree... |
Sorry, something went wrong.
| tick.set_label2(label) | ||
| if not mtransforms.interval_contains(interval_expanded, loc): | ||
| tick.set_visible(False) | ||
| tick.label1.set_visible(False) |
There was a problem hiding this comment.
either also mark the gridline and ticks themselves as invisible, or add a comment about what's happening
Sorry, something went wrong.
There was a problem hiding this comment.
OK< I can do all that, but its a bit ugly. See the second commit. Tempted to just revert #9452, which I think was handling a bit of an edge-case use.
Sorry, something went wrong.
There was a problem hiding this comment.
Or you can just leave a comment on why it is only needed to mark the labels as not visible...
Sorry, something went wrong.
There was a problem hiding this comment.
Preference? I don't have one...
I agree its a bit hincky to have the extra ticks. I forget why we do that?
Sorry, something went wrong.
There was a problem hiding this comment.
I have written in many places that we should be stricter and require the ticker to only return visible ticks (after all it has all the info needed to do so). But I guess that's not happening any time soon and instead we just move the issues further down the stack :/
Sorry, something went wrong.
There was a problem hiding this comment.
Agenda item for today’s call!
Sorry, something went wrong.
| tick.set_label1(label) | ||
| tick.set_label2(label) | ||
| if not mtransforms.interval_contains(interval_expanded, loc): | ||
| tick.set_visible(False) |
There was a problem hiding this comment.
does this line have any effect?
Sorry, something went wrong.
There was a problem hiding this comment.
Might be worth adding the code above as a quick smoke test?
Sorry, something went wrong.
|
I've put this to 2.2.3, since it's a regression in the 2.2 branch. |
Sorry, something went wrong.
|
This is all very confusing, and it seems like a case of whack-a-mole. Isn't there a cleaner solution than putting invisible ticks into a list of ticks to draw? I think @aantzer is pointing to it in his comment #9397 (comment). I suspect the root issue is the interaction between the Locator and autoscaling, and what is needed is an earlier distinction between potential tick locations, relevant to autoscaling, and actual tick locations that will be drawn in the end. This is further complicated by the usual floating point fudge to include a tick that falls an infinitessimal distance beyond the edge. |
Sorry, something went wrong.
|
Sorry. Thought I’d opened an issue for this. Yes ticks that are returned from the locators should just be the ones thatll be drawn not a couple of extra in case of round off errors. This fix is clearly just a bandaid |
Sorry, something went wrong.
|
Closing in lieu of #11004, though feel free to resurrect if we want in 2.2.3 |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
PR Summary
Addresses #10874
This code fails master:
This was originally caused by #9452 adding string data to the tick labels that were not seen. Previously get_window_extent would bail on an empty string. But after #9452 the labels were not empty. But they were never drawn, so they never had self._renderer assigned. This makes the labels to be visible if they are not visible, and that causes get_window_extent to ignore them.
PR Checklist