Repository navigation
Refactoring of SelectionChangedCause needed #26026
Description
Currently the selection changed cause (used in text_field.dart) is used to specify whether or not we want the toolbar to appear after the selection changes. Now that there are many different types of gestures that we use to change selection, it would make more sense to simply directly specify whether we want the toolbar to appear instead of indirectly specifying a selection changed cause.
Activity
jslavitz commentedon Jan 3, 2019
We've decided to just let this be for now as SelectionChangedCause is written pretty deep in the code base.
xster commentedon Jan 18, 2019
I'm gonna re-open this following some offline discussions to hopefully clean up the APIs a bit. cc @HansMuller @justinmc @Hixie
The problem we're trying to solve is that there's ~60 places in code where we're sending this enum around. Most of the creations and inputs leading into the creation of this enum originate from (Cupertino)TextField. They pipe through the widget and rendering layer into RenderEditable and then bubble back out through EditableTextState back to the TextField. In the end, they're read in 3 places to vibrate, show the toolbar and show the selection handles.
EditableText and RenderEditable should be a simple, bare and composable API that's agnostic to what these touch events are and when to respond to them. They should just have APIs like selectPosition, selectWord, showToolbar etc.
Reactions to gesture events are very platform specific and the layers above EditableText that want to cause effects to gesture events should just invoke those effects directly.
github-actions commentedon Aug 30, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.