Add infrastructure for Chrome Actions

chrome/browser/ui/views/toolbar/chrome_actions_registry.h

+// Copyright 2014 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_TOOLBAR_CHROME_ACTIONS_REGISTRY_H_

[sky, 2014/10/15 23:52:30]

I assume this is going to be on mac too? Shouldn't this be promoted to
chrome/browser/ui/toolbar? Same comment for other similar classes.

[Devlin, 2014/10/16 16:46:38]

I had it in ui/toolbar at first, but currently all the implementation is
views-specific, and part of me is wondering which is going to win the race
between this implementation and views-on-mac.  For now, what I settled on was
storing these objects in views (since they are only used there), but trying to
make them abstract enough that we can promote them to be fully
platform-independent if/when we need to.  Would you prefer me to have them there
from the start?

[sky, 2014/10/16 18:13:39]

views on mac is a ways out, I don't even think there is a target release for it
yet. I assume you'll need to get this in the mac before then. I also suspect
that adding non-views bits is going to lead to a cleaner architecture anyway.

[Devlin, 2014/10/16 22:05:27]

Mmkay, promoted to ui/toolbar.

+#define CHROME_BROWSER_UI_VIEWS_TOOLBAR_CHROME_ACTIONS_REGISTRY_H_
+
+#include "base/macros.h"
+#include "base/memory/scoped_vector.h"
+
+class Profile;
+class ToolbarActionViewController;
+
+// The registry for all chrome actions. Chrome actions are actions that live in
+// the toolbar (like extension actions), but are components of chrome, such as
+// ChromeCast.
+class ChromeActionsRegistry {

[sky, 2014/10/15 23:52:30]

nit: I don't think Chrome is very descriptive in the context of the chrome code
base. These actions are mostly shown in the toolbar, so ToolbarActionRegistry is
a much better name. This comment applies to every where you are using Chrome.

I expect a registry to contain add/remove and functions like that. This class
just creates the actions though, should it be ToolbarActionFactory?

[Devlin, 2014/10/16 16:46:38]

Fair point regarding descriptiveness.  I'm kind of hesitant to call it
ToolbarActionFactory because a "ToolbarAction" is currently the terminology used
to describe either a "chrome" action or an extension action - and this only
contains information about the former.  What about
ComponentToolbarActionsFactory (since each represents a component of chrome?)
Done.

[sky, 2014/10/16 18:13:39]

ic. Chrome is an umbrella term, and on a casual read I would expect Chrome to be
the set of 'all' actions. Your use of 'chrome' here really means non-extension
actions, which isn't at all clear. You need a better term for the non-extension
actions.

[Devlin, 2014/10/16 22:05:27]

Is the new name from Patch Set 2 (ComponentToolbarActionFactory, with a broader
term of ComponentToolbarAction) appropriate?

+ public:
+  // For readability, a pointer to a function that has the same signature as
+  // GetChromeActions().
+  typedef ScopedVector<ToolbarActionViewController> (*FactoryFunction)(void);
+
+  // Returns a collection of controllers for Chrome Actions.
+  static ScopedVector<ToolbarActionViewController> GetChromeActions();
+
+  // Set a substitute function to create the chrome actions for testing.
+  static void SetTestingChromeActionsFunction(FactoryFunction function);

[sky, 2014/10/15 23:52:30]

Can tests inject an implementation of this class rather than setting a function?

[Devlin, 2014/10/16 16:46:38]

Sure.  It actually seemed a little messier to me that way, but it is more
scalable if we ever many more methods on the class.

+};
+
+#endif  // CHROME_BROWSER_UI_VIEWS_TOOLBAR_CHROME_ACTIONS_REGISTRY_H_