Implements a PlatformMenuBar widget and associated data structures for defining menu bars that use native APIs for rendering.
This PR includes:
A PlatformMenuBar class, which is a widget that menu bar data can be attached to for sending to the platform.
A PlatformMenuDelegate base, which is the type taken by a new WidgetsBinding.platformMenuDelegate.
An implementation of the above in DefaultPlatformMenuDelegate that talks to the built-in "flutter/menu" channel to talk to the built-in platform implementation. The delegate is so that a plugin could override with its own delegate and provide other platforms with native menu support using the same widgets to define the menus.
This is the framework part of the implementation. The engine part will be in flutter/engine#32080 (and flutter/engine#32358)
This does a cleanup of the examples, removing all of the "section" markers and extra comments that we don't need anymore now that the samples are no longer in the source code. It also removes the --template arguments from the {@tool dartpad} and {@tool sample} directives, since those are no longer used. It converts two examples that I discovered were still embedded into linked examples in the examples folder.
I didn't delete the templates from the snippets config folder yet, because there are still embedded samples in the dart:ui package from the engine that use them. Once dart:ui no longer uses the templates, they can be removed.
I bumped the version of the snippets package to pick up a change that allows removal of the --template argument.
This adds a smoke test for every single API example. It also fixes 17 tests that had bugs in them, or were otherwise broken, and even fixes one actual bug in the framework, and one limitation in the framework.
The bug in the framework is that NetworkImage's _loadAsync method had await response.drain<List<int>>();, but if the response is null, it will throw a cryptic exception saying that Null can't be assigned to List<int>. The fix was just to use await response.drain<void>(); instead.
The limitation is that RelativePositionedTransition takes an Animation<Rect> rect parameter, and if you want to use a RectTween with it, the value emitted there is Rect?, and one of the examples was just casting from Animation<Rect> to Animation<Rect?>, which is invalid, so I modified RelativePositionedTransition to take a Rect? and just use Rect.zero if the rect is null.
* changed controlsBuilder signature
combined all parameters into ControlsDetails class
* sample fixes
* updates to docstrings
* switched to positional argument for stepper.controlsbuilder
* Merge branch 'master' into stepper-builder-fix
This extracts the sample code out from the API doc comments, and places them in separate files on disk, allowing running of the examples locally, testing them, and building of slightly larger examples.
