| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Bundles cascading menu information and stores it in a stack representing
the hierarchy of added menus.
Bug: 23970448
Change-Id: I1621d9eb30ff173767b6ebad2a1977127c42d0ad
|
| |
|
|
|
|
|
|
| |
Introduced some regressions. Reverting until we can do better testing.
This reverts commit 8375d639986529969ea5e118de548d29db16ec97.
Change-Id: I9b15d63e52c814ef8985b86f8a50359e39355d39
|
| |
|
|
|
|
|
|
| |
Bundles cascading menu information and stores it in a stack representing
the hierarchy of added menus.
Bug: 23970448
Change-Id: Icc0a96ea2dd4320fd4dae9626435ed82a6165480
|
| |
|
|
|
|
|
|
| |
This means that right-clicking/long pressing on a view that is registered for
context menu will show the context menu as a popup menu instead.
Bug: 20016398
Change-Id: I96fea60435fff2f981d288521f490f8ff24ada15
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Open submenus now disappear instantly rather than fading out when
mouse hovers over a non-submenu item.
2. When a submenu is opened on hover, the item that was hovered now
will remain selected instead of being deselected.
3. Fix an issue where if the same chain of submenus was opened more
than once, the submenus could open in a different direction each
time. To fix, we keep track of the direction of opening along the way
and make sure to reset the preferred direction when a submenu is
closed.
Bug: 20127825
Change-Id: I99972cce4ddabe316c5148f1dd79a5d7b3e64b87
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the cascading feature is enabled, users can mouseover a
submenu item in a popup menu to expand and open the new submenu
(after a short timeout). Similarly, if a user mouseovers a
different menu item in the original menu, the submenu gets closed
(again, after a short timeout).
This should complete the implementation of cascading submenu
functionality.
Also fix two other issues:
(1) Update some oudated code in PopupMenu that was still opening
the submenu when a user clicks on a submenu item; this
responsibility now lives within the MenuPopupHelper's delegate
MenuPopup class, so it doesn't need to live in PopupMenu anymore.
(2) Fix an issue where icons would be force-set on a submenu when they
should not be. Instead, decide whether to show icons in a submenu
based on whether to show them in the top level menu, as intended.
Bug: 20127825
Change-Id: Ia46852c7f99436065ab4bc234de94dffc0019666
|
| |
|
|
|
|
|
|
|
| |
This change adds a new Cascading implementation of MenuPopup. When
enabled, submenus will show up in a cascading side by side fashion
when opened next to popup menus.
Bug: 20127825
Change-Id: Ie3c797fb5dbada7521cd93dc4171950af2be2ff7
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is in service of desktop-style submenus. Follow up CLs will make
use of the newly independent classes. MOST of the changes in this CL
are simply moving code from one place to another. Below are
descriptions of the new files added:
DropDownListView:
Decouple this from ListPopupWindow, so other "menu popup"
implementations [forthcoming] may make use of it.
This class is UNCHANGED except for the addition of the
setListSelectionHidden method.
ForwardingListener:
Decouple this from ListPopupWindow, so that other clients of this
listener can expect a more general ShowableListMenu rather than a
concrete ListPopupWindow. This will be useful later when we want to
use something other than ListPopupWindow to show a menu.
This class is UNCHANGED, except for (1) using the getListView() on
popup rather than accessing its mDropDownList member, and (2)
replacing ListPopupWindow return values with ShowableListMenu.
MenuAdapter:
Decouple from MenuPopupHelper so it may be used by forthcoming "menu
popup" implementations rather than just by MenuPopupHelper itself.
This class is UNCHANGED.
ShowableListMenu:
A new interface to encapsulate a menu that can be shown or hidden.
This will be implemented by both ListPopupWindow and a forthcoming
"menu popup" class.
Bug: 20127825
Change-Id: I565b444d25e966ff8b8c6ceac7be8de56a9116df
|
|
|
- mouse hover moves the selected item in the menu. It moves
the selection rectangle, and further up/down key or enter
key will start from the hovered item.
- when the mouse exits from the entire popup window, the
selection is canceled. Further up/down key will start from
the first item.
To implement these behaviors, and consider about other keyboard
behaviors which is special to menus, I believe it justifies
to create another class for the menu popups rather than using
ListPopupWindow directly.
Bug: 19642104
Change-Id: I5e405c0491c67fdef9764898701119979ec13a9f
|
