Rather than test that it has zero bindings (although that is a legitimate
test too), test for the thing we're really concerned about here: that it
doesn't have movement keys. That's what this is all about.
Not that this made a change to its passing/failing state right at the moment
-- it's going to fail anyway -- but it kinda needs to be in its proper "this
should pass" state.
This is the heart of the issue introduced by
b48a1402b8
and which is being investigated in
https://github.com/Textualize/textual/issues/1343 -- the child widget can be
focused, but (as far as the author of the code is concerned) it has no
bindings. Bindings for movement-oriented keys exist on the screen which
composes up the widget into it. Up until 0.5.0 this worked just fine. As of
0.6.0, because binding inheritance was introduced, the bindings for movement
that live at the `Widget` level cause the widget that has no bindings to
appear to have bindings.
While this can potentially be worked around with the use of
inherit_bindings, this isn't a very satisfying solution and also breaks the
rule of least astonishment.
This test is going to be key to all of this. This is the test that should be
made to work without breaking any of the other currently-passing tests.
The code is exactly the same between is_container and is_scrollable, and the
intent (confirmed in
https://github.com/Textualize/textual/issues/1343#issuecomment-1347989752)
is that the latter is intended to be overridden in some circumstances (so
far only in `ScrollView`). As such I feel it better conveys intent and
reduces the changes of mismatched future changes if is_scrollable is defined
in respect to is_container.
The only possible reason I can think of is if there's a measurable
performance win here. Applying Knuth for the moment, at least for the scope
of this PR. I strongly suspect this is one of the 97% rather than one of the
3% and for the purposes of moving stuff around (which I may be doing as I
explore this) I believe this makes it easier to follow and to think about.
Rather than just test a single specific movement key (in this case "up"), go
with all the affected keys. The cost to doing so is zero and it means we get
a full coverage of testing for all the keys that have become a problem with
0.6.0.
Up until now there doesn't seem to have been any unit tests aimed squarely
at setting up bindings, as part of a running application, which are only
about testing the bindings. As such there was no way of slotting in tests
for how inheritance of bindings works.
This starts that process with a view to testing how inheriting
likely *should* work.
See #1343 for some background to this.
