This is the one biggish change between the last working test run in GitHub,
and now. Tests are still running locally fine, an on GitHub, in the last
run, I had one job pass and another fail, both on the same OS, just 3.10
passed and 3.9 failed. The problem still to do with (as far as I can tell)
messages inside Textual and some sort of async issue.
So let's try this.
Wondering if this is the issue with why the tests have stopped working in
GitHub; but also not *really* confused as to why they were working in the
first place.
This code is running just finally locally in tests, but is failing with:
RuntimeError: Task <Task pending name='Task-279' coro=<MessagePump._process_messages() running at /home/runner/work/textual/textual/src/textual/message_pump.py:314>> got Future <Future pending> attached to a different loop
in GitHub Actions. Pretty sure I saw this before, which made me add the
pause in the first place. Given this seems to just be affecting the last
test, from what I can tell, let's make the pause longer to see if that
helps.
I hate chasing action issues...
This is set to xfail at the moment because the tested result is what I think
should be the result, but what happens now isn't that. Need to check with
Will to see what he thinks the correct resolution is here.
I feel some more will be needed, but this is all of the basics, hitting all
of the important points that relate to #1343. More importantly all of the
xfails are now removed.
This works in conjunction with BINDINGS. If a widget has BINDINGS, and if
any of those bindings have a priority that isn't True or False, the value of
PRIORITY_BINDINGS will be used (or the value from one of the parent classes,
if there are any, will be used if it isn't set on the current class).
See #1343.
This commit changes things slightly so that the priority of a binding is an
three-state: True, False or None. True and False are firm choices that
nothing else should override. None says "fall back to whatever default is up
for grabs".
The commit also then adds support for a default priority and, when building
a binding, it uses that if the binding has a priority of None.
See #1343.
At the moment at least, we don't allow binding on " ", we bind on "space".
Meanwhile, tidy folk may try and bind in "a, b, c, d" as opposed to trying
to bind on "a,b,c,d". I feel we should allow for that.
This test, which breaks at the moment, should be satisfied.
While what I had worked, asserting on a boolean return from that method
ended up masking what had gone wrong. This way we get to see the fail
and *why* it failed.
The tests are getting a little involved, and aim to tell an important story
about how the binding inheritance works, currently causes problems, and
should eventually work. As such I feel it's time to tidy things up a bit,
reduce some of the copy/paste going on, and comment heavily so I don't lose
my place and thinking, not to mention hopefully help someone else reading
make sense of the tests.
For now anyway. I suspect this definition if is_scrollable will become moot
soon (ideally there would never be an is_scrollable property at all, ever,
as inheritance should ideally dictate this if the changes that are planned
go the way as planned -- a property that tells you something about
provenance when the inheritance tree tells you that is some bad OO smell)
but I want to get the tests set up as their own PR first and *then* work on
the fix.
By making use of __dict__ we have a simpler way of determining if the class defines its own default_css which does not involve comparing with the base class's default_css.
