Spinner widget, event stealing, async "loading screen", Widget trait doc #319
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds a
![spinner](https://user-images.githubusercontent.com/134893/168265542-60d3a271-4ec4-4f87-9c09-8af46a37fc1a.png)
Spinner
widget. Also, spot the new theme colour buttons in the Gallery. (This is with 150% scale factor.)The usual controls are implemented:
To implement up/down and mouse-scroll event handling I added a new method to
Widget
:This is functionality which was lost when
SendEvent::send
was removed; at the time there was not a good rationale for keeping it, but this widget does provide one: the ability to use a complex inner widget likeEditBox
(~1100 lines of code), but customise handling of specific events.Documentation of the
Widget
trait (and co) was improved.Additionally, the
async-event
example now shows a "loading..." message for 1s before async event handling starts. This is just a hint to show that this kind of thing is possible; a larger example might use theStack
widget to switch between the loading message and finished view (or just disable content and use aProgress
mouse cursor).