[ash-md] Added different highlighting modes to the InkDropImpl.

ash/common/shelf/overflow_button.cc

Index: ash/common/shelf/overflow_button.cc
diff --git a/ash/common/shelf/overflow_button.cc b/ash/common/shelf/overflow_button.cc
index 5c848320f94dc2e677a00ab4ce02759333f9bf0d..8677dbafc479f4cfe44dec64223bcd4e98f1ab78 100644
--- a/ash/common/shelf/overflow_button.cc
+++ b/ash/common/shelf/overflow_button.cc
@@ -26,6 +26,7 @@
 #include "ui/gfx/transform.h"
 #include "ui/gfx/vector_icons_public.h"
 #include "ui/views/animation/flood_fill_ink_drop_ripple.h"
+#include "ui/views/animation/ink_drop_impl.h"
 
 namespace ash {
 
@@ -82,6 +83,10 @@ void OverflowButton::OnPaint(gfx::Canvas* canvas) {
   PaintForeground(canvas, bounds);
 }
 
+std::unique_ptr<views::InkDrop> OverflowButton::CreateInkDrop() {
+  return CreateDefaultFloodFillInkDropImpl();

[sky, 2016/11/02 02:52:11]

Is there a way the type of button could be expressed to views so that views
(ideally code outside of views, but that's for another day) could know the type
to create?

[bruthig, 2016/11/04 18:50:36]

I'm currently entertaining a few ideas:

1. Injecting an InkDropFactory
2. Making an InkDropView which is a container and can host child views.  The
InkDropView could be outside of Views and this may allow us to remove the
InkDropHostView from the Views hierarchy.

Agreed though, these scattered CreateInk*Drop() methods are getting out of hand
and difficult to maintain.

[sky, 2016/11/04 20:36:12]

I was thinking more of an enum. What are the set of variations that are needed?

[bruthig, 2016/11/07 18:38:47]

So basically there are 3 parameters (Highlight mode - 3 values, show highlight
on hover - 2 values, and show highlight on focus - 2 values) which means there
are 12 different possible configurations and currently we we are using 6
distinct configurations of an InkDropImpl instance.

Keep in mind that this does not account for all of the different
ripple/highlight configurations which are in general very specific to the UI are
that they are being applied to and this is closely related to the InkDropImpl
configuration.  That is why I was thinking of grouping together the creation of
these three parts into factories.

So, yes I could create an enum in InkDropHostView with 6 values but I don't
think something as simple as an enum is a good long term solution.

+}
+
 std::unique_ptr<views::InkDropRipple> OverflowButton::CreateInkDropRipple()
     const {
   return base::MakeUnique<views::FloodFillInkDropRipple>(
@@ -96,10 +101,6 @@ bool OverflowButton::ShouldEnterPushedState(const ui::Event& event) {
   return CustomButton::ShouldEnterPushedState(event);
 }
 
-bool OverflowButton::ShouldShowInkDropHighlight() const {
-  return false;
-}
-
 void OverflowButton::NotifyClick(const ui::Event& event) {
   CustomButton::NotifyClick(event);
   shelf_view_->ButtonPressed(this, event, ink_drop());