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.
Header.show_clock was just a good old plain object attribute, not a
reactive, and also wasn't done as a read-only property. This means someone
could get the impression that it could be modified on the fly and the header
would react.
There might be an argument for turning it into that; but for the moment this
commit makes it private so that nobody gets the wrong impression.
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.
The changes here roll two issues into one change. With this commit:
- Scrolling up/down/etc using the keyboard now moves just one cell, rather
than moving the number of cells specified by the scroll sensitivity that's
intended for pointing devices. #1897
- Where appropriate the scrolling is done lazily; that is it is done after
the next refresh, helping to ensure that the scroll will take into account
any updates in the same parent call. #1774
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.