Start untangling the avatar switcher from BrowserNonClientFrameView

chrome/browser/ui/views/frame/avatar_button_bridge.h

Index: chrome/browser/ui/views/frame/avatar_button_bridge.h
diff --git a/chrome/browser/ui/views/frame/avatar_button_bridge.h b/chrome/browser/ui/views/frame/avatar_button_bridge.h
new file mode 100644
index 0000000000000000000000000000000000000000..b2206552cfa221bb40e139942f2865ebabb24309
--- /dev/null
+++ b/chrome/browser/ui/views/frame/avatar_button_bridge.h
@@ -0,0 +1,39 @@
+// Copyright 2016 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 CHROME_BROWSER_UI_VIEWS_FRAME_AVATAR_BUTTON_BRIDGE_H_
+#define CHROME_BROWSER_UI_VIEWS_FRAME_AVATAR_BUTTON_BRIDGE_H_
+
+#include "chrome/browser/ui/views/profiles/avatar_button_style.h"
+#include "ui/views/controls/button/button.h"
+
+class BrowserNonClientFrameView;
+
+// Wrapper for an avatar button displayed in a browser frame. The button
+// displays the name of the active or guest profile, and may be null.
+class AvatarButtonBridge : public views::ButtonListener {

[sky, 2016/01/20 17:05:36]

I'm curious why you're naming this with bridge. It doesn't seem at all like the
similarly named classes that go from objective-c to c++. AvatarButtonOwner?
AvatarButtonManager?

[tapted, 2016/01/21 01:33:21]

Yeah - Bridge doesn't really fit. I've gone with AvatarButtonManager.

I also considered diverging a bit more and going with something like
"ProfileSwitcher". However, my lofty vision is to have this manage both the
profile switcher and the incognito indicator [and the CrOS
teleported-window-profile-indicator]. So AvatarButtonManager feels nice there.

I did end up keeping `profile_switcher_` as the data member name though. For
now, it ensures it doesn't get confused with `avatar_button_` (which is
[usually] the incognito icon - there's a todo to rename that already..).

history (re: "bridge"): In an earlier iteration it was effectively just bridging
the `NewAvatarButton` interface (i.e. in the design-pattern sense) by providing
the same API for hit-testing, layout, etc., but allowing code-sharing and
abstracting away the "might-not-exist" aspect. The layout has a lot of
frame-specific logic though, so this approach didn't buy much in the end.

+ public:
+  explicit AvatarButtonBridge(BrowserNonClientFrameView* frame_view);
+
+  // Adds or removes the avatar button from the frame, based on the BrowserView
+  // properties.
+  void Update(AvatarButtonStyle style);
+
+  // Gets the avatar button as a view::View.
+  views::View* view() const { return view_; }
+
+ private:
+  // views::ButtonListener:
+  void ButtonPressed(views::Button* sender, const ui::Event& event) override;
+
+  BrowserNonClientFrameView* frame_view_;  // Weak. Owns |this|.
+
+  // Menu button that displays the name of the active or guest profile.
+  // May be null and will not be displayed for off the record profiles.
+  views::View* view_;  // Owned by views hierarchy.
+
+  DISALLOW_COPY_AND_ASSIGN(AvatarButtonBridge);
+};
+
+#endif  // CHROME_BROWSER_UI_VIEWS_FRAME_AVATAR_BUTTON_BRIDGE_H_