Not only has universal not changed to priority, these bindings are on the
screen and so have priority anyway. This means we can safely go back to how
5x5 was prior to 0.6.0.
The cursor keys stopped working in 5x5 once binding inheritance was
introduced in 0.6.0 (see #1343). Making them `universal` keys here fixes the
issue. This won't be the final form of this change, but this fixes this
example so that it works with 0.6.0 (so anyone cloning down the code and
running with an installed 0.6.0 will get the full effect).
Once the final work resulting from #1343 takes place this will need a final
update (and should be a good test example for the changes).
For the moment this does nothing more than inherit from a Static; but what
it does do is make it easier for someone to add text to their application
and to style it by styling all the Labels. Before now it would be common to
use a Static but if you try and style (or query) all Statics, you'd also get
things like Buttons, which inherit from Static.
See #1190
It was on D (as in uppercase D, or shift-d), but I feel this was going to be
confusing given that there is still this slight mixup with the display of
letters in the footer, and what was bound, etc.
So... make it obvious what to press.
Remember, 'd' can't be used because it's a movement key in this game.
See https://github.com/Textualize/textual/pull/963#discussion_r1000546514
Personally I prefer the approach I was using in that it's one less bit of
hard-coded metadata. On the other hand I can appreciate that reducing the
number of possibly-confusing things in an example plays better with people
who may be both new to Textual *and* to Python.
Because Textual uses on_ for event handlers there was the danger of a name
clash; so to keep things as clear as possible this renames anything to do
with "on" (method names, properties, style classes) so that it talks about
"filled" instead.
See https://github.com/Textualize/textual/pull/963#discussion_r1000544563
It had been suggested to me that these would be needed, but in testing here
I'm not seeing that. So, until I find out otherwise, let's simplify things
and drop that.
Originally I was doing everything in the DOM, using just the primitive
widgets. Given that I recently created an actual GameCell widget (which
simply inherits from a Button, but still...) it makes sense to now have
row/col properties as part of that.
