Repository navigation
Context menu API #30976
Description
Objective
Design a set of API for context menu that meets the following requirements:
- Easy and intuitive for developers to apply to their custom widgets
- Provide default context menu for certain widgets:
- EditableText
- SelectableText (upcoming)
- (Please add more)
- Widgets with default context menu should allow override
- Menu should be rendered in proper style, which should be apparent to widgets
- In a material app it should be rendered in Material PopupMenu
- In a desktop app or on Web, it should be rendered in native menu (long-term goal)
Activity
dkwingsmt commentedon May 31, 2019
Progress as of 5/31/2019, #33685
What's in this PR
As shown in the GIF above, this PR contains the following features:
Feature-wise this should be close to complete as a first phase, except for perhaps the following features:
Please correct me if we have plan for more.
Current API
There are two dimensions of extensibility, which are independent from each other:
Content control
ContextMenuContentis a configuration of what to show in a context menuContextMenuEntryis an entry in a context menu. It is platform-neutral, unlikePopupMenuEntry. It has subclasses such as menu item, divider, and submenus.TextContextMenuFactoryis how editable text will define its context menu.Render control
RenderContextMenuis an abstract class that platforms can implement how to render the menu and each kind of menu entry.showMenu._MaterialRenderContextMenuis an implementation of materialRemaining question
How to design the API for rendering control?
Currently
EditableTexthas two new parameters in this PR:TextContextMenuFactory contextMenuFactorycontrols contentRenderContextMenu renderContextMenucontrols renderIt makes sense to keep
contextMenuFactoryas a parameter ofEditableText, butrenderContextMenushould really be a global configuration. I wonder what the idiomatic way is for this (should I design another class that has static method.of?)Will
RenderContextMenuwork for native menu?I would really like to make it work on at least one platform before confirming, such as macOS and Web.
How to design API for menu entry?
It will very likely depend on the upcoming
ActionAPI.[-]Add context menu to editable text[/-][+]Context menu API[/+]krisgiesing commentedon Jun 3, 2019
Just so I understand the direction here: is the intention that (at least initially) the context menu would be drawn by Flutter rather than by the platform? This has the observable effect of needing to draw within Flutter's window, rather than at an edge where some of the rendering occurs outside the window.
dkwingsmt commentedon Jun 3, 2019
@krisgiesing Menu drawn by Flutter will be used on Android, or as a fallback (e.g. on GLFW).
The long-term plan is to eventually use native menu when possible, such as on Desktops and on Web.
But yes, it will be the initial implementation.
Also +cc @stuartmorgan @gspencergoog
dkwingsmt commentedon Aug 5, 2019
Update as of 8/5/2019:
Development on this has been paused.
Multiple problems were found. One of them is #34025, which severely affects user experience, but I'm not aware of solution or workaround unless we re-implement modals into multiple activities (?).
I'm still planning to come back and implement a non-extensible context menu that supports basic operations at some point.
gspencergoog commentedon Nov 13, 2019
Closing this as a duplicate of #31955
github-actions commentedon Aug 14, 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.