This workaround was created 6 years ago with no links to bug databases to track. As best we can determine, the issue is no longer present in SkPicture or DisplayList and is most likely obsolete. More importantly, though, non-rendering primitives are ignored by the DisplayList construction and so this workaround will just be ignored anyway. If a problem surfaces about this issue that we haven't discovered by a thorough code search of the current code base, then workarounds should be installed within the relevant implementation modules rather than in the framework (and documented with bugs filed in either or both of Flutter's github repos, and/or the Skia issue database).
Workaround originally created in this PR: https://github.com/flutter/flutter/pull/9654
- Added `InlineWidgetContainerDefaults` for deduping inline widget code
- Added a helper function `WidgetSpan.extractFromInlineSpan` for extracting `WidgetSpan`s and automatically applying text scaling (at widget level)
- Removed `TextPainter.inlinePlaceholderScales`. I'm going to deprecate the `scale` argument in `TextPainter.addPlaceholder` next, as scaling is now done at the widget level.
- Added runtime check and comments to make sure nobody is extending `PlaceholderSpan` directly (unfortunately we can't remove `PlaceholderSpan` without moving RenderEditable and RenderParagraph to the widgets library).
Reverts flutter/flutter#127052, which seems to be breaking the build
because of a goldens failure.
```
The following TestFailure was thrown running a test:
Expected: one widget whose rasterized image matches golden image "shadow.PhysicalModel.enabled.png"
Actual: _WidgetTypeFinder:<exactly one widget with type "Container" (ignoring offstage widgets):
Container(bg: Color(0xfffff59d), margin: EdgeInsets.all(150.0))>
```
See
https://ci.chromium.org/ui/p/flutter/builders/prod/Linux%20web_tests_6/11051/overview
This workaround was created 6 years ago with no links to bug databases to track. As best we can determine, the issue is no longer present in SkPicture or DisplayList and is most likely obsolete. More importantly, though, non-rendering primitives are ignored by the DisplayList construction and so this workaround will just be ignored anyway. If a problem surfaces about this issue that we haven't discovered by a thorough code search of the current code base, then workarounds should be installed within the relevant implementation modules rather than in the framework (and documented with bugs filed in either or both of Flutter's github repos, and/or the Skia issue database).
Workaround originally created in this PR: https://github.com/flutter/flutter/pull/9654
* Add test for RenderProxyBoxMixin; clarify doc, resolve TODO
The TODO comment suggested this mixin would no longer be needed once
a Dart issue on inherited constructors was fixed:
https://github.com/dart-lang/sdk/issues/31543
That issue is now long since fixed, so I went to go carry out the TODO.
But in doing so, I realized that the mixin's documentation was more
right than the TODO comment: even with that issue fixed, there is a
legitimate use case for this mixin, namely to reuse the implementation
of RenderProxyBox in a class that also inherits from some other base
class. Moreover, searching GitHub I found an example of a library
that makes real use of that capability.
So I think the right resolution is to accept that this separation
is useful and delete the TODO.
Then, add a test with an extremely simplified sketch of that
real-world example. In case someone in the future attempts to
simplify this mixin away, the test will point us at the use case
that would be broken by such a change.
Also remove the only in-tree use of the mixin, which was redundant;
and expand the mixin's documentation to advise about that case.
* Tweak formatting
Co-authored-by: Michael Goderbauer <goderbauer@google.com>
* Cut comments
---------
Co-authored-by: Michael Goderbauer <goderbauer@google.com>
This implements a MenuBar widget that can render a Material menu bar, and a MenuAnchor widget used to create a cascading menu in a region. The menus are drawn in the overlay, while the menu bar itself is in the regular widget tree. Keyboard traversal works between the two.
This implementation of the MenuBar uses MenuAnchor to create a cascading menu that contains widgets representing the menu items. These menu items can be any kind of widget, but are typically SubmenuButtons that host submenus, or MenuItemButtons that have shortcut hints (but don't actually activate the shortcuts) and don't host submenus.
Cascading menus can be created outside of a MenuBar by using a MenuAnchor. They can be either given a specific location to appear (a coordinate), or they can be located by the MenuAnchor region that wraps the control that opens them.
The developer may also create a MenuController to pass to the various menu primitives (MenuBar or MenuAnchor) to associate menus so that they can be traversed together and closed together. Creating a controller is not required.
* Implement trackpad gestures in framework
* Touch and Pan/Zoom pointers have separate IDs now
* Handle trackpad pointer device type
* Respect supportedDevices for pan/zoom events
* Update after rebase
* Fix check failures
* Avoid error with very short drags
* Address feedback
* Refactor drag event handler
* Address more feedback
* Add some missing punctuation
* fix deprecated_new_in_comment_reference for `material` library
in a future version of the SDK, these will be flagged, fix them now
* Update pubspec.yaml
