To the best of my knowledge, and in testing myself, border and border_* are
properties of a widget's `styles` property, they're not a property of the
widget itself.
Unlike a few other widgets, the RadioSet is pretty much all about reacting
to the selection result; the question of how you go about it has already
come up and while the message is documented, complete with all properties,
it can't hurt to have an illustrative example of code that uses it.
Here I add an extra RadioSet example that sits with the message in the
reference. This should help the reader better follow how to use it, and also
gives something to link to if someone hasn't got that far into the
documentation yet but is attempting to use the RadioSet.
* remove sender
* removed priority post
* timer fix
* test fixes
* drop async version of post_message
* extended docs
* fix no app
* Added control properties
* changelog
* changelog
* changelog
* fix for stopping timers
* changelog
* added aliases to radio and checkbox
* Drop sender from Message init
* drop time
* drop cast
* Added aliases
Adds missing documentation for disabled to each of the button variant
constructors, and also pulls in a couple more public-visible Button-related
types into the docs.
There's a couple of other types in the public interface of Tree that should
be teased out, and it feels odd to have one type in one file and a bunch of
others in another. So this sets us up for having them all the same place.
This should make it easier for the reader to find related information.
While it's arguably not the most useful widget, it's in the code, exported,
and can be seen by people; I feel it should be in the documentation. I've
ensured that it also links to Placeholder given it sort of is a Placeholder
and so people might arrive at it first and it makes sense to redirect them
to something more comprehensive.
Add a warning to my first blog post, letting the attentive reader know that
`emit_no_wait` doesn't exist any more, and linking them to what they should
be using if they want to do their own custom messages.
While the code here isn't exactly written as a play-along tutorial, it's
reasonable to expect that some one can and will. This commit has been
written because exactly that situation happened.
The problem here is without the ID on the label the layout will end up
looking very different from that shown in the docs; which will halt the
reader's flow as they try and figure out what they did wrong.
Counterpoint: this is a guide, not a tutorial, so it seemed reasonable to
only highlight the important thing that's changing. Personally I think I'd
argue in favour of highlighting all the changes from question01 to
question02.
Addresses #1905.
See #1364 -- rather than pull in specific classes, this pulls in every
publicly-documented item (function, class, type, "constant", etc) that can
be found in each of the modules.
This should help improve the linkage of types within the documentation.
A large part of the code to go with this is to show off a radio set; I feel
it makes sense to use the same code for both bits of documentation given
that a radio button only really makes sense inside a radio set.
