Refactor ViewsDelegate and MD-ify the icon-to-text spacing for checkbox and radiobutton

ui/views/layout/layout_constants.h

Index: ui/views/layout/layout_constants.h
diff --git a/ui/views/layout/layout_constants.h b/ui/views/layout/layout_constants.h
index a0ab3f1abe59ded939903d8ddc6d98cc744a28fb..80bbce6cd37855da89949f2e483dc4db5d4baaee 100644
--- a/ui/views/layout/layout_constants.h
+++ b/ui/views/layout/layout_constants.h
@@ -83,6 +83,10 @@ constexpr int kCheckboxIndent = 10;
 // and the start of its corresponding text.
 constexpr int kItemLabelSpacing = 10;
 
+// Horizontal spacing between the image of a label button and its text. This
+// affects checkboxes and radiobuttons.
+constexpr int kIconTextSpacing = 5;

[sky, 2017/02/17 20:50:46]

Isn't the goal to effectively get rid of this file? If we don't, folks will
still use it and miss routing through ViewsDelegate. Can you move the constant
to views_delegate.cc? It looks like the constant is referenced in Harmony, can
it call to ViewsDelegate?

[kylix_rd, 2017/02/17 21:40:51]

That would then be a circular reference, which would lead to an infinite loop or
stack overflow. 

The goal is to eliminate the LayoutDelegate and incorporate it all into
ViewsDelegate. This would then resolve the circular reference.

[sky, 2017/02/17 22:39:03]

I was hoping you could call directly to the base implementation.

[Peter Kasting, 2017/02/18 00:52:58]

Yes.  And I'm not a huge fan of how LayoutDelegate and ViewsDelegate have
different ideas of when they want to return a number versus a gfx::Insets.  I
think this is primarily because we've been building LayoutDelegate to return
single numbers, and the existing APIs there do that, but we probably want to
return real Insets from it anyway.

I would make the goal for the initial ViewsDelegate refactoring CL to not have
any overlap between ViewsDelegate and LayoutDelegate constants.  If
views_delegate.h declares a metric, then that metric (or a component thereof)
probably should not appear in layout_delegate.h.

The most straightforward way to achieve this would probably be to create a
views-level LayoutDelegate, containing all the metrics needed in views/, with a
Chrome-side subclass extending it for further Chrome-specific metrics, and then
move all of this entirely out of ViewsDelegate.  (This is bug 687349 comment 3.)

The other way is what the bug originally describes, which is to nuke the
metric-related functions from LayoutDelegate (but leave it around for other
things), and move them into ChromeViewsDelegate, splitting the enum into two
pieces.

Neither one of these is the work of five minutes to implement, which is why I
hadn't gotten to this yet :)

+
 }  // namespace views
 
 #endif  // UI_VIEWS_LAYOUT_LAYOUT_CONSTANTS_H_