Fix typos / errors in doc comments (#38558)
This commit is contained in:
parent
a11d73148c
commit
c161ac898c
@ -33,7 +33,7 @@ abstract class GestureArenaMember {
|
||||
void rejectGesture(int pointer);
|
||||
}
|
||||
|
||||
/// An interface to information to an arena.
|
||||
/// An interface to pass information to an arena.
|
||||
///
|
||||
/// A given [GestureArenaMember] can have multiple entries in multiple arenas
|
||||
/// with different pointer ids.
|
||||
|
@ -88,7 +88,7 @@ mixin GestureBinding on BindingBase implements HitTestable, HitTestDispatcher, H
|
||||
|
||||
/// Dispatch a [PointerCancelEvent] for the given pointer soon.
|
||||
///
|
||||
/// The pointer event will be dispatch before the next pointer event and
|
||||
/// The pointer event will be dispatched before the next pointer event and
|
||||
/// before the end of the microtask but not within this function call.
|
||||
void cancelPointer(int pointer) {
|
||||
if (_pendingPointerEvents.isEmpty && !locked)
|
||||
|
@ -102,7 +102,7 @@ typedef GestureTapCancelCallback = void Function();
|
||||
///
|
||||
/// Gesture recognizers take part in gesture arenas to enable potential gestures
|
||||
/// to be disambiguated from each other. This process is managed by a
|
||||
/// [GestureArenaManager] (q.v.).
|
||||
/// [GestureArenaManager].
|
||||
///
|
||||
/// [TapGestureRecognizer] considers all the pointers involved in the pointer
|
||||
/// event sequence as contributing to one gesture. For this reason, extra
|
||||
|
@ -1142,7 +1142,7 @@ class _IntrinsicDimensionsCacheEntry {
|
||||
/// [constraints] given by the parent to the child were tight constraints.)
|
||||
///
|
||||
/// For [RenderBox] classes that do not inherit from [RenderProxyBox], once they
|
||||
/// have laid out their children, should also position them, by setting the
|
||||
/// have laid out their children, they should also position them, by setting the
|
||||
/// [BoxParentData.offset] field of each child's [parentData] object.
|
||||
///
|
||||
/// #### Layout of non-RenderBox children
|
||||
@ -2076,11 +2076,11 @@ abstract class RenderBox extends RenderObject {
|
||||
/// This [RenderBox] is responsible for checking whether the given position is
|
||||
/// within its bounds.
|
||||
///
|
||||
/// If transforming is necessary, [HitTestResult.addWithPaintTransform],
|
||||
/// [HitTestResult.addWithPaintOffset], or [HitTestResult.addWithRawTransform] need
|
||||
/// to be invoked by the caller to record the required transform operations
|
||||
/// in the [HitTestResult]. These methods will also help with applying the
|
||||
/// transform to `position`.
|
||||
/// If transforming is necessary, [BoxHitTestResult.addWithPaintTransform],
|
||||
/// [BoxHitTestResult.addWithPaintOffset], or
|
||||
/// [BoxHitTestResult.addWithRawTransform] need to be invoked by the caller
|
||||
/// to record the required transform operations in the [HitTestResult]. These
|
||||
/// methods will also help with applying the transform to `position`.
|
||||
///
|
||||
/// Hit testing requires layout to be up-to-date but does not require painting
|
||||
/// to be up-to-date. That means a render object can rely upon [performLayout]
|
||||
|
@ -90,7 +90,7 @@ abstract class Layer extends AbstractNode with DiagnosticableTreeMixin {
|
||||
|
||||
/// Traverse the layer tree and compute if any subtree needs [addToScene].
|
||||
///
|
||||
/// A subtree needs [addToScene] if any of its layer needs [addToScene].
|
||||
/// A subtree needs [addToScene] if any of its layers need [addToScene].
|
||||
/// The [ContainerLayer] will override this to respect its children.
|
||||
@protected
|
||||
@visibleForTesting
|
||||
|
@ -380,7 +380,7 @@ class PaintingContext extends ClipContext {
|
||||
///
|
||||
/// * `needsCompositing` is whether the child needs compositing. Typically
|
||||
/// matches the value of [RenderObject.needsCompositing] for the caller.
|
||||
/// * `offset` is the offset from the origin of the canvas' coordinate system
|
||||
/// * `offset` is the offset from the origin of the canvas's coordinate system
|
||||
/// to the origin of the caller's coordinate system.
|
||||
/// * `clipRect` is rectangle (in the caller's coordinate system) to use to
|
||||
/// clip the painting done by [painter].
|
||||
@ -1405,7 +1405,8 @@ abstract class RenderObject extends AbstractNode with DiagnosticableTreeMixin im
|
||||
///
|
||||
/// Some subclasses of [RenderObject], notably [RenderBox], have other
|
||||
/// situations in which the parent needs to be notified if the child is
|
||||
/// dirtied. Such subclasses override markNeedsLayout and either call
|
||||
/// dirtied (e.g., if the child's intrinsic dimensions or baseline changes).
|
||||
/// Such subclasses override markNeedsLayout and either call
|
||||
/// `super.markNeedsLayout()`, in the normal case, or call
|
||||
/// [markParentNeedsLayout], in the case where the parent needs to be laid out
|
||||
/// as well as the child.
|
||||
@ -1532,7 +1533,7 @@ abstract class RenderObject extends AbstractNode with DiagnosticableTreeMixin im
|
||||
///
|
||||
/// This method is the main entry point for parents to ask their children to
|
||||
/// update their layout information. The parent passes a constraints object,
|
||||
/// which informs the child as which layouts are permissible. The child is
|
||||
/// which informs the child as to which layouts are permissible. The child is
|
||||
/// required to obey the given constraints.
|
||||
///
|
||||
/// If the parent reads information computed during the child's layout, the
|
||||
@ -1836,7 +1837,8 @@ abstract class RenderObject extends AbstractNode with DiagnosticableTreeMixin im
|
||||
/// Mark the compositing state for this render object as dirty.
|
||||
///
|
||||
/// This is called to indicate that the value for [needsCompositing] needs to
|
||||
/// be recomputed during the next [flushCompositingBits] engine phase.
|
||||
/// be recomputed during the next [PipelineOwner.flushCompositingBits] engine
|
||||
/// phase.
|
||||
///
|
||||
/// When the subtree is mutated, we need to recompute our
|
||||
/// [needsCompositing] bit, and some of our ancestors need to do the
|
||||
|
@ -150,7 +150,7 @@ enum SchedulerPhase {
|
||||
/// Microtasks scheduled during the processing of transient callbacks are
|
||||
/// current executing.
|
||||
///
|
||||
/// This may include, for instance, callbacks from futures resulted during the
|
||||
/// This may include, for instance, callbacks from futures resolved during the
|
||||
/// [transientCallbacks] phase.
|
||||
midFrameMicrotasks,
|
||||
|
||||
|
@ -713,7 +713,7 @@ mixin WidgetsBinding on BindingBase, SchedulerBinding, GestureBinding, RendererB
|
||||
/// sent to the GPU.
|
||||
///
|
||||
/// 8. The semantics phase: All the dirty [RenderObject]s in the system have
|
||||
/// their semantics updated (see [RenderObject.semanticsAnnotator]). This
|
||||
/// their semantics updated (see [RenderObject.assembleSemanticsNode]). This
|
||||
/// generates the [SemanticsNode] tree. See
|
||||
/// [RenderObject.markNeedsSemanticsUpdate] for further details on marking an
|
||||
/// object dirty for semantics.
|
||||
|
@ -44,7 +44,7 @@ typedef ScrollableWidgetBuilder = Widget Function(
|
||||
/// between the range of minChildSize and maxChildSize (as percentages of the
|
||||
/// parent container's height) as long as the builder creates a widget which
|
||||
/// uses the provided [ScrollController]. If the widget created by the
|
||||
/// [ScrollableWidgetBuilder] does not use provided [ScrollController], the
|
||||
/// [ScrollableWidgetBuilder] does not use the provided [ScrollController], the
|
||||
/// sheet will remain at the initialChildSize.
|
||||
///
|
||||
/// By default, the widget will expand its non-occupied area to fill available
|
||||
|
@ -825,7 +825,7 @@ class FocusNode with DiagnosticableTreeMixin, ChangeNotifier {
|
||||
/// as the [focusedChild] of this node, adopting if it isn't already part of the
|
||||
/// focus tree.
|
||||
///
|
||||
/// {@macro flutter.widgets.focusManager.lifecycle}
|
||||
/// {@macro flutter.widgets.focus_manager.focus.lifecycle}
|
||||
/// {@macro flutter.widgets.focus_manager.focus.keyEvents}
|
||||
///
|
||||
/// See also:
|
||||
@ -999,7 +999,7 @@ enum FocusHighlightStrategy {
|
||||
/// See also:
|
||||
///
|
||||
/// * [FocusNode], which is a node in the focus tree that can receive focus.
|
||||
/// * [FocusScopeNode], which is an node in the focus tree used to collect
|
||||
/// * [FocusScopeNode], which is a node in the focus tree used to collect
|
||||
/// subtrees into groups.
|
||||
/// * [Focus.of], which provides the nearest ancestor [FocusNode] for a given
|
||||
/// [BuildContext].
|
||||
|
@ -1246,8 +1246,8 @@ abstract class State<T extends StatefulWidget> extends Diagnosticable {
|
||||
/// ### Why is the [build] method on [State], and not [StatefulWidget]?
|
||||
///
|
||||
/// Putting a `Widget build(BuildContext context)` method on [State] rather
|
||||
/// putting a `Widget build(BuildContext context, State state)` method on
|
||||
/// [StatefulWidget] gives developers more flexibility when subclassing
|
||||
/// than putting a `Widget build(BuildContext context, State state)` method
|
||||
/// on [StatefulWidget] gives developers more flexibility when subclassing
|
||||
/// [StatefulWidget].
|
||||
///
|
||||
/// For example, [AnimatedWidget] is a subclass of [StatefulWidget] that
|
||||
@ -2569,7 +2569,7 @@ class BuildOwner {
|
||||
/// state. When this happens, the framework will call [update] with the new
|
||||
/// widget. The new widget will always have the same [runtimeType] and key as
|
||||
/// old widget. If the parent wishes to change the [runtimeType] or key of
|
||||
/// the widget at this location in the tree, can do so by unmounting this
|
||||
/// the widget at this location in the tree, it can do so by unmounting this
|
||||
/// element and inflating the new widget at this location.
|
||||
/// * At some point, an ancestor might decide to remove this element (or an
|
||||
/// intermediate ancestor) from the tree, which the ancestor does by calling
|
||||
@ -4411,7 +4411,7 @@ class InheritedElement extends ProxyElement {
|
||||
///
|
||||
/// Subclasses can manage these values with [updateDependencies]
|
||||
/// so that they can selectively rebuild dependents in
|
||||
/// [notifyDependents].
|
||||
/// [notifyDependent].
|
||||
///
|
||||
/// This method is typically only called in overrides of [updateDependencies].
|
||||
///
|
||||
@ -4438,7 +4438,7 @@ class InheritedElement extends ProxyElement {
|
||||
/// null by default so that dependent elements are rebuilt unconditionally.
|
||||
///
|
||||
/// Subclasses can manage these values with [updateDependencies]
|
||||
/// so that they can selectively rebuild dependents in [notifyDependents].
|
||||
/// so that they can selectively rebuild dependents in [notifyDependent].
|
||||
///
|
||||
/// This method is typically only called in overrides of [updateDependencies].
|
||||
///
|
||||
@ -4468,7 +4468,7 @@ class InheritedElement extends ProxyElement {
|
||||
/// [dependent].
|
||||
///
|
||||
/// Subclasses can manage their own dependencies values so that they
|
||||
/// can selectively rebuild dependents in [notifyDependents].
|
||||
/// can selectively rebuild dependents in [notifyDependent].
|
||||
///
|
||||
/// See also:
|
||||
///
|
||||
|
@ -72,7 +72,7 @@ enum Orientation {
|
||||
/// Widgets whose layouts consume space defined by [viewInsets], [viewPadding],
|
||||
/// or [padding] should enclose their children in secondary MediaQuery
|
||||
/// widgets that reduce those properties by the same amount.
|
||||
/// The [removePadding], [removeViewPadding], and [removeInsets] methods are
|
||||
/// The [removePadding], [removeViewPadding], and [removeViewInsets] methods are
|
||||
/// useful for this.
|
||||
/// See also:
|
||||
///
|
||||
|
@ -41,7 +41,7 @@ typedef NestedScrollViewHeaderSliversBuilder = List<Widget> Function(BuildContex
|
||||
/// their scroll positions being intrinsically linked.
|
||||
///
|
||||
/// The most common use case for this widget is a scrollable view with a
|
||||
/// flexible [SliverAppBar] containing a [TabBar] in the header (build by
|
||||
/// flexible [SliverAppBar] containing a [TabBar] in the header (built by
|
||||
/// [headerSliverBuilder], and with a [TabBarView] in the [body], such that the
|
||||
/// scrollable view's contents vary based on which tab is visible.
|
||||
///
|
||||
|
Loading…
x
Reference in New Issue
Block a user