The idea here is that not every widget will scroll, and as such not every
widget needs to have default bindings for calling the scrolling methods.
Generally scrolling is something done in a container.
These days we have *Scroll containers. As such it makes sense to introduce
the bindings in a common parent class for those containers.
This commit moves the binding from widget and creates that common parent
class, and then has HorizontalScroll and VerticalScroll inherit from it.
This is, it should be noted, a breaking change. Any code that creates a
scrolling widget that assumes that the bindings are just there, where that
widget doesn't inherit either from HorizontalScroll or VerticalScroll, will
suddenly find that scrolling with the keyboard is no longer possible.
See #2332.
Under normal circumstances the code wouldn't encounter this problem as
there's always a default screen; but a handful of tests that were testing
the screen stack broke after the recent additions relating to result
callbacks.
This cleans up that problem.
* Add regression test for #2229.
* Fix potential reactive-watch loop.
* Simplify regression test.
Labels are cheaper to use and the final visual result of the test won't depend on the directory it runs from.
* Simplify solution.
Turns out I didn't need a descriptor. :(
* Fail on empty tab.
It is possible for the same instance of a screen to get pushed onto the
screen stack multiple times; as such we really need to keep track of all the
callback requests.
So here I register a callback for every screen push and clean it up on every
screen pop; with those without callbacks being no-ops.
This is roughly how it should work. Having got this going and constructed
test code to go with it (outwith of this commit, not unit testing code, just
a test app to try out the ideas), I wanted to get this onto the forge for
further mulling over tomorrow.
The one sneaky/questionable thing here is that I'm sort of dumpster-diving
the screen stack to get the "parent" screen, to make the callback in
context. This both feels right and feels like a cheat. On the other hand
it's public for a reason, right?
Right?
I'm not 100% sure how to get this into the docs as I'd like, and it seems
we've moved the API docs around a lot in respect to widgets, recently (I'm
aware of this but aren't sure what the new layout is yet).
This at least starts to get things into the right place.
