Deciding if there was a change when turning all on or off by looking at the
before an after counts was fine, but it's not a sensible way of seeing if
there was a change during a toggle. So this swaps things up a bit and has
the core selection changing methods return a flag to say if they actually
made a change or not.
Adding back docstrings from overriding methods. Initially I was thinking it
made sense to keep them empty, allowing for any inheriting of the
docs (if/when our documentation generation system does that); but in most
cases there's a subtle difference in what's supported in terms of parameters
or return values so it makes sense to tweak the docs a wee bit.
The developer using this may wish to react to UI changes being made, but
they may also want to just know when the collection of selected values has
changed -- this could happen via code so won't get any UI/IO messages. So
this adds a message that is always sent when a change to the collection of
selected values happens.
It would be nice to just inherit form the OptionList messages, but the
naming of the properties wouldn't quite make sense, and there's also the
generic typing issue too. So here I start to spin up my own messages down
here.
Also, as an initial use of this, grab the OptionList highlight message and
turn it onto one of out own.
Mostly I feel it makes sense to have the value first, and the actual prompt
second (based on no reason at all); but given that Select does it prompt
then value, this should conform to the same approach.
The implicit type was creating mypy errors when defining bindings with
tuples. For example:
class MyApp(App):
BINDINGS = [("q", "quit", "Quit")]
Would give the error:
error: List item 0 has incompatible type "Tuple[str, str, str]"; expected "Binding" [list-item]
With #1719 in mind, and as an alternative to #2608, this allows for a child
class of DirectoryTree to specify how a fresh `Path` should be created. The
idea here being that whatever is created should be of the `Path` type, but
can have other abilities.
Now that I'm no longer having to dodge issues with getting component classes
before the DOM has spun up, I can go back to the simpler method of setting
up the selections.
This also means I can drop Mount handling.
More experimenting with overriding OptionList, and rather than trying to
swap out and around the prompt under the hood, I got to thinking that it
made more sense to perhaps override render_line.
So far so good...
