[MD] Implement incognito colors as a NativeTheme (for Aura).

ui/native_theme/native_theme_aura_dark.h

Index: ui/native_theme/native_theme_aura_dark.h
diff --git a/ui/native_theme/native_theme_aura_dark.h b/ui/native_theme/native_theme_aura_dark.h
new file mode 100644
index 0000000000000000000000000000000000000000..19f0a787913a484bb5c2ce037bbd5e5a9b2f4a18
--- /dev/null
+++ b/ui/native_theme/native_theme_aura_dark.h
@@ -0,0 +1,32 @@
+// 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.
+
+#ifndef UI_NATIVE_THEME_NATIVE_THEME_AURA_OFF_THE_RECORD_H_
+#define UI_NATIVE_THEME_NATIVE_THEME_AURA_OFF_THE_RECORD_H_
+
+#include "base/macros.h"
+#include "ui/native_theme/native_theme_aura.h"
+
+namespace ui {
+
+// Aura implementation of native theme support for dark mode (used for
+// incognito).
+class NATIVE_THEME_EXPORT NativeThemeAuraDark : public NativeThemeAura {

[Peter Kasting, 2015/11/11 00:34:46]

I'm a bit concerned that on Windows we're proposing to use NativeThemeWin
normally and NativeThemeAuraDark for incognito, since the inheritance chains
are:

NativeTheme -> NativeThemeWin
NativeTheme -> NativeThemeBase -> NativeThemeAura -> NativeThemeAuraDark

I worry about what sorts of differences will result from this besides just a few
colors.  It would be more reassuring if the new "dark" theme was a subclass or
direct sibling to the "normal" theme class in all cases.

It's making me wonder whether we're barking up the wrong tree; perhaps instead
of a different NativeTheme class, we should be using some sort of mixin object
to get colors and icons that can differ between normal and incognito mode,
either in the ultimate consumer, or inside the NativeThemeXXX implementation
itself?  Or maybe we should actually put "return incognito ? x : y" sorts of
statements directly into the functions in NativeThemeWin or the like?

[Evan Stade, 2015/11/11 01:05:32]

Well, incognito ? x : y doesn't sound that viable because all the native theme
instances are singletons, and I don't see how it helps us much anyway (just
mixes the two different themes together). The reason I went with a
NativeThemeAura subclass is that NativeThemeAura contains some shared logic
(e.g. SkColorSetA) for both incognito and normal profiles, but yea, this may
mess up widget drawing for Windows?

How about this:

class NativeThemeAuraDark : public NativeThemeAura {...}
class NativeThemeWinDark : public NativeThemeWin {
  SkColor GetColor(id) { return NativeThemeAuraDark::GetColor(id); }
}

Eventually if we find colors that shouldn't be the same on Windows incognito we
can add those before the NativeThemeAuraDark redirect.

[Peter Kasting, 2015/11/11 01:25:47]

It'd mean we'd have to pass in relevant state.  That may be enough to sink the
idea.
That sort of route seems preferable.  I don't know that we could be quite this
simple -- we might need to do something like:

  SkColor NativeThemeAuraDark::GetColor(int id, bool* specifies_color) {
    *specifies_color = true;
    switch (id) {
      ...
      default:
        *specifies_color = false;
        return;
    }
  }

  SkColor NativeThemeAuraDark::GetColor(int id) {
    bool specifies_color;
    SkColor color = GetColor(id, &specifies_color);
    return specifies_color ? color : NativeThemeAura::GetColor(id);
  }

  SkColor NativeThemeWinDark::GetColor(int id) {
    bool specifies_color;
    SkColor color = GetColor(id, &specifies_color);
    return specifies_color ? color : NativeThemeWin::GetColor(id);
  }

Whether we need this depends on whether the dark theme has to replace literally
every color or not.  My suspicion is that it doesn't, and some things (link
color?) might be left "as-is", in which case we want to make sure Windows uses
the NativeThemeWin behaviors instead of the NativeThemeAura ones.
Yeah, that'd be easy.

[Evan Stade, 2015/11/11 01:32:30]

So are you happy starting off with this plan?

FWIW, link color is incognito specific. I think pretty much 100% of colors will
be incognito specific because once you start changing backgrounds, everything
else has to change too.

+ public:
+  static NativeThemeAuraDark* instance();
+
+ protected:
+  NativeThemeAuraDark();
+  ~NativeThemeAuraDark() override;
+
+  // Overridden from NativeThemeBase:
+  SkColor GetSystemColor(ColorId color_id) const override;
+
+ private:
+  DISALLOW_COPY_AND_ASSIGN(NativeThemeAuraDark);
+};
+
+}  // namespace ui
+
+#endif  // UI_NATIVE_THEME_NATIVE_THEME_AURA_H_