Refactoring of SelectionChangedCause needed

[jslavitz]

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.

[jslavitz]

We've decided to just let this be for now as SelectionChangedCause is written pretty deep in the code base.

[xster]

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.

• Add tons of tests for all existing behaviors and APIs around TextField, CupertinoTextField, EditableText and RenderText
• Draft a plan for a soft-API-break migration to remove SelectionChangeCause
• Submit to flutter-announce for feedback
• Refactor
• Create an intermediate layer for adherence to platform gesture touch conventions between Material/Cupertino and EditableText for developers who want to create a custom text field.

[github-actions]

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 -v and a minimal reproduction of the issue.