Add support for windowed auto-ranging

[bryevdv]

• issues: fixes Windowed Auto-ranging #10020
• tests added / passed
• release document entry (if new feature or API change)

Some example of the windowed auto-ranging in action are at the bottom of this OP.

Questions

• Is a configuration like window_axis on Plot the best API? I thought about other options, e.g. a configuration on glyphs, or on data ranges. But ultimately, it can never make sense to have two ranges auto-range off each other at the same time. Therefore, my conclusion was that the configuration had to be at a "higher" level, i.e. on the Plot so that the possibility for that kind of mis-configuration could be avoided entirely.

• Are there any thoughts or issues about the implementation approach itself? It turned out to be rather simple though possibly there are use cases I've overlooked. Currently verified that things work when window range is updated from stream following, or pan or zoom tools, also that reset tool turns windowed auto-ranging back on in case an interaction explicitly sets the auto-range extents. Also that having all the data "fall off" the window does not blow up anything.

• Where is the best place to add documentation for this? cc @tcmetzger Are there other examples that could be updated besides these two?

---

[bryevdv]

@mattpap I thought the CI would generate new baseline files for missing images, etc but when I download the new artifact there is nothing new in it to commit?

Edit also I thought we ran at least the unit tests in non-linux BokehJS CI jobs? If not and all we do is run the lint check, do we really actually need these extra jobs at all?

[bryevdv]

This is ready, modulo the question about how to get brand-new baseline files which seem to not be getting included in the report.

[mattpap]

modulo the question about how to get brand-new baseline files which seem to not be getting included in the report.

This is Windows thing. This should work if you replace " with ' in baseline's name.

[mattpap]

Release notes are missing. I will finish reviewing this tomorrow.

[bryevdv]

This is Windows thing. This should work if you replace " with ' in baseline's name.

@mattpap Sorry, I don't follow. I downloaded bokehjs-report.zip (which I think is generated on the ubunu job?) and unzipped it on my macbook, and this is all that's there:

base ❯ unzip bokehjs-report.zip
Archive:  bokehjs-report.zip
  inflating: bokehjs/test/baselines/linux/report.json
  inflating: bokehjs/test/baselines/linux/report.out

I am not using windows and AFAIK neither is the CI that generates the artifact. Can you be more specific about what needs updating, and where?

Edit: I guess maybe you mean change the "${wax}" in the test name to this?

      it(`with window_axis='${wax}' when range changes`, async () => {

maybe there is a way we can lint for this...

[mattpap]

maybe there is a way we can lint for this...

I added validation in PR #14387.

[bryevdv]

@mattpap this is ready for re-review

[mattpap]

I really would like others on @bokeh/dev to join in help reviewing PRs. In particular in this PR at least discuss the API. Based on the discussion in the yesterday's meeting, Bokeh 3.8 should have a much shorter release cycle, about a month, and mostly include existing work. In particular any CSS breaking changes will be postponed for 3.9 (we will work in parallel to get CSS changes early in 3.9 development). Thus I would prefer to merge this PR in 3.8 and give us some time work with this and potentially refine this over the next month.

[bryevdv]

@mattpap do you have specific concerns? I did have some questions at first but that was a few weeks ago. I'm now personally quite happy with things at this point. I would very much like this to go in 3.7.

Edit: elaborating on this, I think the impossibility of supporting a "both" option places very hard constraints on the API. It has to go "above" the ranges themselves in order to coordinate, i.e. on the plot objects. So then it just comes down to naming, and I think this name is reasonable and lots of bike shedding is not needed. Beyond that, any implementation issues or bugs can be addressed in the next cycle.

[mattpap]

I did have some questions at first but that was a few weeks ago. I'm now personally quite happy with things at this point. I would very much like this to go in 3.7.

I reviewed this on technical level and it's fine. However, I'm not sure if I'm the right person to approve this on API/functional level. If you think this is solid and you don't expect immediate changes in the next release, then I can approve it.

[bryevdv]

If you think this is solid and you don't expect immediate changes in the next release, then I can approve it.

👍 I don't expect any changes, fortunately the API surface needed is quite minimal.

[mattpap]

OK, in this case PR is approved.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.