You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now it is only possible to have the Cupertino and material appearance of the selection control. And this is limited to the Copy/Cut/Paste/Select All options.
Having the ability to customize the selection control would bring us more freedom to build custom solutions.
Do you want to search on google a selected text? Or call a selected phone number? Highlight the selected text? Make it bold?
The implementation doesn't look difficult as it would be just adding the optional param and use it if it is not null and isSelectabe = true. Check here were to add it.
@guidezpl Besides they are similar, I don't think they are the same.
The issue #31412 is to implement new options to the current materialTextSelectionControls/cupertinoTextSelectionControls.
This issue is about allowing developers to implement our own TextSelectionControl besides the already implemented ones materialTextSelectionControls/cupertinoTextSelectionControls.
Right now the only solution would be to implement our own SelectableText and that is not something affordable as a lot of important widgets depend on this one.
Yeah it makes sense to me that the selection menu should be totally customizable. If we do simply pipe through a selectionControls parameter, I'm not sure how nice the experience will be of creating a custom TextSelectionControls will be right now. We'll have to try it out and see, maybe there is more we can do to make this approachable.
I think piping selectionControls param would allow a high level of personalization but not very intuitive for most developers. I would personally that option and in a close future create a TextSelectionControls that simplifies the process for the general case of a DecoratedBox/CustomWidget that allows a row of widgets inside that can interact with the text. (eg. Medium controls).
After I finish my GSoC project this week, I will try to create my own TextSelectionControls and provide some extra feedback.
@SeasonLeee I believe we talked a bit on Discord, but please keep me updated with what your company needs out of the text selection menu customization!
Hey @justinmc, I have updated my example with some new ideas. The class TextSelectionToolbar has become 'ContextMenu' and they can now be used both inside and EditableText widget and in another widget ( similar to PopupMenuButton). If they are used as TextSelectionToolbars they will have access to the clipboard and text selection features.
Apart from the material and Cupertino TextSelectionToolbars, I also started with
I would like to make the current ContextMenuItems become Widgets, but keeping the flexibility they have now. Still a lot of work to do but I think it is good enough for a general idea.
@jamesblasco Awesome, thank you for the update! I'm getting back to looking at this today. We may go forward with your PR #66785 for now while I continue my work in investigating how to bring your solution into the framework. That PR would unblock @SeasonLeee. I'll respond soon when I have a better understanding of the changes.
@jamesblasco I've merged #69428, which makes it much easier to build a custom text selection menu without needing to duplicate quite as much code. The API is still not ideal, but it's much better.
Thanks, @justinmc! Great work! I have been following your example repo for a while and I think the overall api is good.
Maybe it would be great to hide the logic from the clipboard and Paste/Copy/Cut/Select handlers and make it accessible from the context through an InheritedWidget.
Yess, maybe moving to a widget together with a StatefulWidget that listens to ClipboardStatusNotifier changes.
As the TextSelectionDelegate will be the same for that widget, we could move these functions from that class to the widget tree.
We probably don't need TextSelectionControls, which is probably a different idea.
Because depending on the platform, the toolbar doesn't necessarily show up after it's selected, it could be that the toolbar shows up when you click on a blank space, or it could be a special design (like autocomplete as long as GitHub @ someone's and the rest of the behavior follows the theme).
I was wondering if I could have EditableText notify AncestorWidget of the cursor size and position.
Then some AncestorWidget would receive this data and draw a different toolbar as needed (we'd need to implement the default MD style and Cupertion style, of course). And the AncestorWidget can also control the show and hide of the toolbar, and can distinguish between different trigger events.
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.
Activity
[-]Custom TextSelectionControls[/-][+]Allow custom TextSelectionControls inside SelectableText[/+]jamesblasco commentedon Jun 15, 2020
Use case
Right now it is only possible to have the Cupertino and material appearance of the selection control. And this is limited to the Copy/Cut/Paste/Select All options.
Having the ability to customize the selection control would bring us more freedom to build custom solutions.
Do you want to search on google a selected text? Or call a selected phone number? Highlight the selected text? Make it bold?
The implementation doesn't look difficult as it would be just adding the optional param and use it if it is not null and isSelectabe = true. Check here were to add it.
jerryan999 commentedon Jul 28, 2020
waiting for this feature
guidezpl commentedon Aug 28, 2020
Closing, as duplicate of #31412
jamesblasco commentedon Aug 28, 2020
@guidezpl Besides they are similar, I don't think they are the same.
The issue #31412 is to implement new options to the current materialTextSelectionControls/cupertinoTextSelectionControls.
This issue is about allowing developers to implement our own TextSelectionControl besides the already implemented ones materialTextSelectionControls/cupertinoTextSelectionControls.
Right now the only solution would be to implement our own SelectableText and that is not something affordable as a lot of important widgets depend on this one.
guidezpl commentedon Aug 28, 2020
Ah sorry, I understand now. Seems like a reasonable ask. Basically plumbing SelectableText to https://api.flutter.dev/flutter/widgets/EditableText/selectionControls.html from Selectable. We may want to also want this in TextField and CupertinoTextField. @justinmc What do you think?
justinmc commentedon Aug 28, 2020
Yeah it makes sense to me that the selection menu should be totally customizable. If we do simply pipe through a selectionControls parameter, I'm not sure how nice the experience will be of creating a custom TextSelectionControls will be right now. We'll have to try it out and see, maybe there is more we can do to make this approachable.
Plus I do plan to fix #31412 when I have time.
jamesblasco commentedon Aug 28, 2020
I think piping selectionControls param would allow a high level of personalization but not very intuitive for most developers. I would personally that option and in a close future create a TextSelectionControls that simplifies the process for the general case of a
DecoratedBox/CustomWidgetthat allows a row of widgets inside that can interact with the text. (eg. Medium controls).After I finish my GSoC project this week, I will try to create my own TextSelectionControls and provide some extra feedback.
7 remaining items
renntbenrennt commentedon Oct 12, 2020
Our company's next project is heavily rely on customizable selection control, so I really need your help, thanks!!!
justinmc commentedon Oct 12, 2020
@SeasonLeee I believe we talked a bit on Discord, but please keep me updated with what your company needs out of the text selection menu customization!
jamesblasco commentedon Oct 13, 2020
Hey @justinmc, I have updated my example with some new ideas. The class
TextSelectionToolbarhas become 'ContextMenu' and they can now be used both inside and EditableText widget and in another widget ( similar to PopupMenuButton). If they are used as TextSelectionToolbars they will have access to the clipboard and text selection features.Apart from the material and Cupertino TextSelectionToolbars, I also started with
CascadeContextMenu(ref: https://twitter.com/saketme/status/1314834865469222917?s=20)CupertinoPullDownMenu(ref: Pull-Down Menus for iOS 14 #60298)I also started playing with nested menus:
I would like to make the current
ContextMenuItemsbecome Widgets, but keeping the flexibility they have now. Still a lot of work to do but I think it is good enough for a general idea.https://github.com/jamesblasco/selection_controls_example/tree/context_menu
renntbenrennt commentedon Oct 13, 2020
@justinmc Yeah, sure thing! And thanks for all the detailed responses, you are the best😆
@jamesblasco and man, your work is phenomenal!!!! Thanks for all your contributions!!! I will have a look on that!
justinmc commentedon Oct 13, 2020
@jamesblasco Awesome, thank you for the update! I'm getting back to looking at this today. We may go forward with your PR #66785 for now while I continue my work in investigating how to bring your solution into the framework. That PR would unblock @SeasonLeee. I'll respond soon when I have a better understanding of the changes.
justinmc commentedon Oct 14, 2020
I think we should go forward with #66785. I've left a comment on it.
justinmc commentedon Dec 15, 2020
@jamesblasco I've merged #69428, which makes it much easier to build a custom text selection menu without needing to duplicate quite as much code. The API is still not ideal, but it's much better.
I have an example of how to build a custom menu here: https://github.com/justinmc/flutter-text-selection-menu-examples/blob/master/lib/custom_menu_page.dart
Next I'll try to do the same for iOS, so I'l keep this issue open until then.
jamesblasco commentedon Dec 15, 2020
Thanks, @justinmc! Great work! I have been following your example repo for a while and I think the overall api is good.
Maybe it would be great to hide the logic from the clipboard and Paste/Copy/Cut/Select handlers and make it accessible from the context through an InheritedWidget.
justinmc commentedon Dec 29, 2020
Do you mean the handles for the default text selection menu buttons, like this one?
flutter/packages/flutter/lib/src/widgets/text_selection.dart
Line 238 in 38fe7e2
jamesblasco commentedon Dec 30, 2020
Yess, maybe moving to a widget together with a
StatefulWidgetthat listens toClipboardStatusNotifierchanges.As the TextSelectionDelegate will be the same for that widget, we could move these functions from that class to the widget tree.
So from your example:
https://github.com/justinmc/flutter-text-selection-menu-examples/blob/master/lib/custom_menu_page.dart
Do like:
In the example I made I have something similar to what I am saying here:
https://github.com/jamesblasco/selection_controls_example/blob/master/lib/src/selection_toolbar_controller.dart
YeungKC commentedon Jan 12, 2021
We probably don't need TextSelectionControls, which is probably a different idea.
Because depending on the platform, the toolbar doesn't necessarily show up after it's selected, it could be that the toolbar shows up when you click on a blank space, or it could be a special design (like autocomplete as long as GitHub @ someone's and the rest of the behavior follows the theme).
I was wondering if I could have EditableText notify AncestorWidget of the cursor size and position.
Then some AncestorWidget would receive this data and draw a different toolbar as needed (we'd need to implement the default MD style and Cupertion style, of course). And the AncestorWidget can also control the show and hide of the toolbar, and can distinguish between different trigger events.
I think this design will be more flexible.
cc @justinmc @jamesblasco
justinmc commentedon Jan 19, 2021
Let's continue this discussion in #73574.
github-actions commentedon Aug 6, 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.