Adds ash::MaterialDesignController

ash/material_design/material_design_controller.cc

+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include <string>
+
+#include "ash/ash_switches.h"
+#include "ash/material_design/material_design_controller.h"
+#include "base/command_line.h"
+#include "base/logging.h"
+#include "base/trace_event/trace_event.h"
+
+namespace ash {
+
+bool MaterialDesignController::is_mode_initialized_ = false;
+bool MaterialDesignController::mode_ = false;
+
+// static
+void MaterialDesignController::Initialize() {
+  TRACE_EVENT0("startup", "ash::MaterialDesignController::InitializeMode");
+  CHECK(!is_mode_initialized_);
+  if (base::CommandLine::ForCurrentProcess()->HasSwitch(
+          switches::kAshDisableMaterialDesign)) {
+    SetMode(false);
+  } else if (base::CommandLine::ForCurrentProcess()->HasSwitch(
+                 switches::kAshEnableMaterialDesign)) {

[oshima, 2016/04/26 05:56:37]

By the way, I personally prefer not to have two flags because you can't tell
which one has priority.
(--ash-disable-material-design --ash-enable-material-design disable the mode,
but you can't tell unless you read the code)

Alternative way is to have a boolean flag, true by default

--ash-enable-material-design (implies=true)
--ash-enable-material-design=false

You don't have to change. Just an idea you may want to consider next time.

[varkha, 2016/04/26 15:06:02]

oshima@, how strongly do you feel about it? I can see pros and cons for all
approaches and I've tried to carefully consider them.
- simple value (enabeld / disabled):
  lacks "default" and so needs code changes when we change what that default
maps to
  impossible to change to default in about://flags
- special value (like top-chrome-md)
  this works well and would be my second choice
  has custom values for what should be boolean
  is flexible (but more so than what we need here)
- tri-state default / enabled / disabled (such as in this CL)
  works well for our case
  when wrapped in a controller class is safe to use regarding your priority
concern
  maps to 2 separate flags (this is unfortunate but we support it this way for
many other flags)
Readability is a real concern. Do you think documenting this precedence in a
header file would alleviate it?

[oshima, 2016/04/26 16:06:57]

I don't have strong feeling about this. This is just FYI.
You can. See my example of use-zoom-for-dsf.
I'm not worry much about it assuming that this is very short lived.

+    SetMode(true);
+  } else {
+    SetMode(DefaultMode());
+  }
+}
+
+// static
+bool MaterialDesignController::IsMaterial() {
+  CHECK(is_mode_initialized_);
+  return mode_;
+}
+
+// static
+bool MaterialDesignController::DefaultMode() {
+  return false;
+}
+
+// static
+void MaterialDesignController::SetMode(bool mode) {
+  mode_ = mode;
+  is_mode_initialized_ = true;
+}
+
+// static
+void MaterialDesignController::Uninitialize() {
+  is_mode_initialized_ = false;
+}
+
+}  // namespace ui