Modifying the BackgroundModeManager to handle multiple profiles.

chrome/browser/profiles/profile_status_menu_model.h

Index: chrome/browser/profiles/profile_status_menu_model.h
===================================================================
--- chrome/browser/profiles/profile_status_menu_model.h	(revision 0)
+++ chrome/browser/profiles/profile_status_menu_model.h	(revision 0)
@@ -0,0 +1,39 @@
+// Copyright (c) 2011 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_PROFILES_PROFILE_STATUS_MENU_MODEL_H_
+#define CHROME_BROWSER_PROFILES_PROFILE_STATUS_MENU_MODEL_H_

[Andrew T Wilson (Slow), 2011/05/20 00:22:09]

I'm not sure this is heavy-weight enough to deserve its own class and I don't
know that I'd put it in the profiles/ directory.

I would do one of the following instead:

1) Change this to be a general purpose template class that allows you to specify
any arbitrary type to be passed along with ExecuteCommand() (and possibly all
the other SimpleMenuModel delegate APIs) and put it in ui/base/models
2) Just make this class private to BackgroundModeManager.
3) Maybe rename BackgroundModeData to something like BackgroundModeForProfile,
make it a real class, implement SimpleMenuModel::Delegate on that class which
already has its own reference to the profile. You could even refactor all of the
status icon/context menu code into that class and out of BackgroundModeManager.

If we are going to continue having multiple status icons (one for each profile)
then i'd say #3 is the way to go. If we're going with Glen's suggestion to just
have a single status icon with multiple per-profile submenus, then probably #1
or #2 would be better because we'd need to keep the status icon functionality in
BackgroundModeManager.

[rpetterson, 2011/05/20 05:53:17]

So the real reason that it is its own class is because Miranda had need for a
similar one so the hope is that this one class will serve both our purposes.

1) It seemed pretty specific to be in base.
2) Miranda needed it in her class as well.
3) I'd pick this option. But it would eliminate others using a profile specific
menu. I'll let Miranda chime in on this one as to whether she wants the class or
not.

[Miranda Callahan, 2011/05/20 15:20:17]

Actually, I think that my menu class needs a vector of profiles, not a single
one -- I should have realized this when we talked yesterday, but my brain was
absent.  Let's do #3. I still like the separate icons for separate profiles
idea, based on my own usage -- but of course, we can change later if others come
to different conclusions on wider usage.

+#pragma once
+
+#include "base/string16.h"
+#include "base/task.h"
+#include "ui/base/models/simple_menu_model.h"
+
+class Profile;
+
+// An implement of SimpleMenuModel which adds profile information when
+// executing a command.
+class ProfileStatusMenuModel : public ui::SimpleMenuModel {
+ public:
+  class Delegate : public ui::SimpleMenuModel::Delegate {
+   public:
+    // Performs the action associated with the specified command id.
+    virtual void ExecuteCommand(int command_id, Profile* profile) = 0;
+
+   protected:
+    virtual ~Delegate() {}
+  };
+
+  explicit ProfileStatusMenuModel(Delegate* delegate, Profile* profile);
+  virtual ~ProfileStatusMenuModel();
+
+  virtual void ActivatedAt(int index) OVERRIDE;
+
+ private:
+  Delegate* delegate_;
+
+  Profile* profile_;
+};
+
+#endif  // CHROME_BROWSER_PROFILES_PROFILE_MENU_MODEL_H_