Move text selection theme to widget libraries #99576
Conversation
There was a problem hiding this comment.
In general I understand why you want to do this, but I think it is going to cause more problems than it solves. Perhaps if we had started with a base theme system in widgets and then had Material and Cupertino subclasses this would work better. But as it stands this breaks the current pattern that we use for all the other themes, which would be confusing to learn and would require very careful documentation.
I will think about this some more and see if there is way we could make this work. Or perhaps @HansMuller has some idea about how to handle this better.
(Also it looks like there are some test failures due to the introduction of TextSelectionTheme widgets in the tree where they didn't use to exist).
| textSelectionTheme ??= TextSelectionThemeData( | ||
| selectionColor: colorScheme.primary.withOpacity(0.40), | ||
| selectionHandleColor: colorScheme.primary, | ||
| cursorColor: colorScheme.primary, | ||
| ); |
There was a problem hiding this comment.
This is totally different from the pattern that is currently used for ThemeData objects. They always default to completely empty data object and are only used to override defaults, not provide them here.
Not saying we can't do this, but it would be confusing as it is not consistent with all the other ThemeData classes. We would have to document this special case which would make it harder to learn the theme APIs.
There was a problem hiding this comment.
I think i should be able to avoid this by deriving the text selection them in MaterialApp build method instead. will do that
| @@ -154,7 +158,7 @@ class TextSelectionTheme extends InheritedTheme { | |||
| /// ``` | |||
| static TextSelectionThemeData of(BuildContext context) { | |||
| final TextSelectionTheme? selectionTheme = context.dependOnInheritedWidgetOfExactType<TextSelectionTheme>(); | |||
| return selectionTheme?.data ?? Theme.of(context).textSelectionTheme; | |||
| return selectionTheme?.data ?? const TextSelectionThemeData(); | |||
There was a problem hiding this comment.
This again breaks the existing model, where the fallback values come from the surrounding ThemeData. If an app configured their ThemeData.textSelectionTheme it would not be used for defaults here, right?
There was a problem hiding this comment.
This is following the same pattern of DefaultTextStyle
|
Hi @darrenaustin, thanks for reviewing! The problem I am facing is that RichText needs the selection color to draw the selection highlight. If we don't create some kind of the inherited widget, developers then have to provide selection color for every text widgets, which will be a real pain. If we do create inherited widget, the API will be the same as TextSelectionTheme. That's why i decided to move TextSelectionTheme. I am trying to follow the pattern of DefaultTextStyle, although I think we should probably call it DefaultTextSelectionStyle instead of TextSelectionTheme to avoid confusing. but I am not sure whether it is worth it to rename to class and be a breaking change. |
This comment was marked as outdated.
This comment was marked as outdated.
1b22619 to
ffa21d4
Compare
ffa21d4 to
a325cd4
Compare
|
a friendly bump |
There was a problem hiding this comment.
I'd like to suggest an alternative design, one that's a much closer analog to DefaultTextStyle.
// Defined in the widgets library
class DefaultTextSelectionStyle extends InheritedTheme {
...
final Color? focusedSelectionColor
final Color? selectionColor
final Color? cursorColor
final Color? focusedCursorColor
final Color? focusedSelectionHandleColor
final Color? selectionHandleColor
}The focused variants enable apps to define the selection color that implies that the highlighted text will react to copy/paste/delete clipboard operations.
Widgets that depend on DefaultTextSelectionStyle.of(context) will have to provide defaults for null colors. WidgetsApp will create a fully specified DefaultTextSelectionStyle based on the underlying platform.
It's not possible to use MaterialStateProperty types here because any widget (not just Material widgets) needs to be able to lookup these colors.
TextSelectionThemeData will need to add focused variants of the existing three color properties, all of which will default to the unqualified property (for the sake of backwards compatibility). For example focusedSelectionColor will default to selectionColor. Although supporting MaterialStateColor values for the existing properties would cover this, it seems marginally worthwhile to keep this class's API the same as DefaultTextSelectionStyle.
final Color? focusedSelectionColor
final Color? focusedCursorColor
final Color? focusedSelectionHandleColorMaterialApp should create a fully-specified DefaultTextStyle based on the theme's textSelectionTheme with defaults drawn from the inherited (WidgetsApp) DefaultTextSelectionStyle.
TextSelectionTheme should create a DefaultTextStyle. Note also: TextSelectionTheme (the inherited widget) seems to be rarely used (in other words it seems unlikely that this particular change will cause any backwards compatibility problems).
|
closed in the favor of #100719 |
|
FWIW I prefer the implementation here, theming via the widget tree instead of the theme is odd.
What's the reason behind that ? If it was swapped where every theme data object provided defaults, it might be easier to find default values |
Moves the text selection theme to widget layer to be reused by Global selection
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.