MD Settings: add a <controlled-radio-button>

MD Settings: add a <controlled-radio-button>

It's a new control (currently in settings) that wraps a
<paper-radio-button> and a <cr-pref-policy-indicator> and magically
manages whether the radio button is controlled/disabled and whether the
indicator should show (when the pref is controlled and this specific
option is the effective value).

Because <controlled-radio-button> internally depends on settings-shared
styles, I didn't need to change:

  paper-radio-button {

selectors to:

  paper-radio-button,
  controlled-radio-button {

as I had to with <controlled-button> (as selectors like
paper-button.primary-button specifically made assumptions about tag
names).

I also had to update what <settings-radio-group> considers selectable.

Q: Which {paper,settings,controlled}-radio* thing should I use?

A: If a radio group is backed by a managable pref (ex: use NTP as homepage,
what to do on startup), it should use:

  <settings-radio-group pref="...">
    <controlled-radio-button name="..." pref="...">

If radio group displays a pref but there's no policy to manage it (ex:
device scrolling mode):

  <settings-radio-group pref="...">
    <paper-radio-button name="...">

If a radio group doesn't deal with a pref at all (ex: channel switcher):

  <paper-radio-group>
    <paper-radio-button name="...">

R=stevenjb@chromium.org
BUG=614265
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Committed: https://crrev.com/ff2144883b2063fa79b38a99d27a4f270a934993
Cr-Commit-Position: refs/heads/master@{#409929}

[Dan Beam, 2016-08-04 01:09:26]

Description was changed from

==========
MD Settings: add a <controlled-radio-button>

It's a new control (currently in settings) that wraps a
<paper-radio-button> and a <cr-pref-policy-indicator> and magically
manages whether the radio button is controlled/disabled and whether the
indicator should show (when the pref is controlled and this specific
option is the effective value).

Because <controlled-radio-button> internally depends on settings-shared
styles, I didn't need to change:

  paper-radio-button {

selectors to:

  paper-radio-button,
  controlled-radio-button {

as I had to with <controlled-button> (as selectors like
paper-button.primary-button specifically made assumptions about tag
names).

I also had to update what <settings-radio-group> considers selectable.


Q: Which {paper,settings,controlled}-radio* thing should I use?

A: If a radio group is backed by a managable pref (ex: use NTP as homepage,
what to do on startup), it should use:

  <settings-radio-group pref="...">
    <controlled-radio-button name="..." pref="...">

If radio group displays a pref but there's no policy to manage it (ex:
device scrolling mode):

  <settings-radio-group pref="...">
    <paper-radio-button name="...">

If a radio group doesn't deal with a pref at all (ex: channel switcher):

  <paper-radio-group>
    <paper-radio-button name="...">

R=stevenjb@chromium.org
BUG=614265
==========

to

==========
MD Settings: add a <controlled-radio-button>

It's a new control (currently in settings) that wraps a
<paper-radio-button> and a <cr-pref-policy-indicator> and magically
manages whether the radio button is controlled/disabled and whether the
indicator should show (when the pref is controlled and this specific
option is the effective value).

Because <controlled-radio-button> internally depends on settings-shared
styles, I didn't need to change:

  paper-radio-button {

selectors to:

  paper-radio-button,
  controlled-radio-button {

as I had to with <controlled-button> (as selectors like
paper-button.primary-button specifically made assumptions about tag
names).

I also had to update what <settings-radio-group> considers selectable.


Q: Which {paper,settings,controlled}-radio* thing should I use?

A: If a radio group is backed by a managable pref (ex: use NTP as homepage,
what to do on startup), it should use:

  <settings-radio-group pref="...">
    <controlled-radio-button name="..." pref="...">

If radio group displays a pref but there's no policy to manage it (ex:
device scrolling mode):

  <settings-radio-group pref="...">
    <paper-radio-button name="...">

If a radio group doesn't deal with a pref at all (ex: channel switcher):

  <paper-radio-group>
    <paper-radio-button name="...">

R=stevenjb@chromium.org
BUG=614265
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

[Dan Beam, 2016-08-04 01:16:34]

sorry, forgot screenshot: http://i.imgur.com/qysNi7U.png

[Dan Beam, 2016-08-04 01:16:42]

The CQ bit was checked by dbeam@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-04 01:17:12]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-04 01:59:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-04 01:59:52]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[stevenjb, 2016-08-04 20:50:28]

lgtm

[Dan Beam, 2016-08-04 21:27:47]

The CQ bit was checked by dbeam@chromium.org

[Dan Beam, 2016-08-04 21:27:47]

The patchset sent to the CQ was uploaded after l-g-t-m from
stevenjb@chromium.org
Link to the patchset: https://codereview.chromium.org/2210063002/#ps20001
(title: "remove radio-group tests")

[commit-bot: I haz the power, 2016-08-04 21:28:03]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-04 22:38:27]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-04 22:38:28]

Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Dan Beam, 2016-08-04 22:43:40]

The CQ bit was checked by dbeam@chromium.org

[commit-bot: I haz the power, 2016-08-04 22:44:19]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-04 23:22:53]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-08-04 23:24:56]

Description was changed from

==========
MD Settings: add a <controlled-radio-button>

It's a new control (currently in settings) that wraps a
<paper-radio-button> and a <cr-pref-policy-indicator> and magically
manages whether the radio button is controlled/disabled and whether the
indicator should show (when the pref is controlled and this specific
option is the effective value).

Because <controlled-radio-button> internally depends on settings-shared
styles, I didn't need to change:

  paper-radio-button {

selectors to:

  paper-radio-button,
  controlled-radio-button {

as I had to with <controlled-button> (as selectors like
paper-button.primary-button specifically made assumptions about tag
names).

I also had to update what <settings-radio-group> considers selectable.


Q: Which {paper,settings,controlled}-radio* thing should I use?

A: If a radio group is backed by a managable pref (ex: use NTP as homepage,
what to do on startup), it should use:

  <settings-radio-group pref="...">
    <controlled-radio-button name="..." pref="...">

If radio group displays a pref but there's no policy to manage it (ex:
device scrolling mode):

  <settings-radio-group pref="...">
    <paper-radio-button name="...">

If a radio group doesn't deal with a pref at all (ex: channel switcher):

  <paper-radio-group>
    <paper-radio-button name="...">

R=stevenjb@chromium.org
BUG=614265
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

to

==========
MD Settings: add a <controlled-radio-button>

It's a new control (currently in settings) that wraps a
<paper-radio-button> and a <cr-pref-policy-indicator> and magically
manages whether the radio button is controlled/disabled and whether the
indicator should show (when the pref is controlled and this specific
option is the effective value).

Because <controlled-radio-button> internally depends on settings-shared
styles, I didn't need to change:

  paper-radio-button {

selectors to:

  paper-radio-button,
  controlled-radio-button {

as I had to with <controlled-button> (as selectors like
paper-button.primary-button specifically made assumptions about tag
names).

I also had to update what <settings-radio-group> considers selectable.

Q: Which {paper,settings,controlled}-radio* thing should I use?

A: If a radio group is backed by a managable pref (ex: use NTP as homepage,
what to do on startup), it should use:

  <settings-radio-group pref="...">
    <controlled-radio-button name="..." pref="...">

If radio group displays a pref but there's no policy to manage it (ex:
device scrolling mode):

  <settings-radio-group pref="...">
    <paper-radio-button name="...">

If a radio group doesn't deal with a pref at all (ex: channel switcher):

  <paper-radio-group>
    <paper-radio-button name="...">

R=stevenjb@chromium.org
BUG=614265
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Committed: https://crrev.com/ff2144883b2063fa79b38a99d27a4f270a934993
Cr-Commit-Position: refs/heads/master@{#409929}
==========

[commit-bot: I haz the power, 2016-08-04 23:24:57]

Patchset 2 (id:??) landed as
https://crrev.com/ff2144883b2063fa79b38a99d27a4f270a934993
Cr-Commit-Position: refs/heads/master@{#409929}