Add ChromeBrowserMainExtraParts for non main parts.

chrome/browser/chrome_browser_parts.h

Index: chrome/browser/chrome_browser_parts.h
diff --git a/chrome/browser/chrome_browser_parts.h b/chrome/browser/chrome_browser_parts.h
new file mode 100644
index 0000000000000000000000000000000000000000..345c512ab9e1544fb5e7ea6963cd12a1aabcda7a
--- /dev/null
+++ b/chrome/browser/chrome_browser_parts.h
@@ -0,0 +1,44 @@
+// 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_CHROME_BROWSER_PARTS_H_
+#define CHROME_BROWSER_CHROME_BROWSER_PARTS_H_
+
+#include "base/basictypes.h"
+#include "base/compiler_specific.h"
+
+// Interface class for Parts owned by ChromeBrowserMainParts.
+// The default implementation for all methods is empty.
+
+// Most of these map to content::BrowserMainParts methods. This interface is
+// separate to allow stages to be further subdivided for Chrome specific
+// initialization stages (e.g. browser process init, profile init).
+
+class ChromeBrowserParts {

[jam, 2011/11/14 19:45:55]

it's confusing to have both ChromeBrowserParts and ChromeBrowserMainParts since
both are parts for the BrowserMain function.

As I understand it, the existing ChromeBrowserMainParts is really the main
BrowserMainparts for Chrome. So how about we call that
ChromeMainBrowserMainParts? Then it has a collection of ChromeBrowserMainParts
implementations.

[stevenjb, 2011/11/14 23:31:10]

I agree it is confusing, but I specifically avoided "Main" in the name of
ChromeBrowserParts. These parts are owned by the Chrome specific
BrowserMainParts class (ChromeBrowserMainParts), however these are not really
"main" parts, they are orthogonal sub-parts, and they do not derive from
BrowserMainParts.

Also, the names are currently consistent with the derived sub-classes, e.g.
ChromeBrowserMainPartsLinux, and ChromeBrowserPartsViews. (See:
https://docs.google.com/drawings/d/1nlCHttFS6BAFawce6AM-AcyOhgTl7ptCod1NZznoc...
 for a diagram).

I'd much rather discuss naming strategies offline and do any renaming as a
separate CL. 

[jam, 2011/11/15 00:10:51]

Sorry to nit, but I don't quite follow this argument. These classes are all
called from BrowserMain, so they are all "parts" of the BrowserMain function,
and not just a generic Browser scope. There is already a "Browser" class in
chrome/browser/ui, so BrowserParts would indicate that a class is part of that,
and not BrowserMain.
I think these all have to be renamed as well. All of these classes are in use
during the BrowserMain function, and making their name contain "BrowserMain"
instead of just "Main" makes it obvious that these are called inside the
BrowserMain function, and not throughout the browser process' lifetime.
If you want to rename this in the change after this, that's fine too. However
this class shouldn't go in as ChromeBrowserParts only to be renamed right after
to ChromeBrowserMainParts.

+ public:
+  ChromeBrowserParts();
+  virtual ~ChromeBrowserParts();
+
+  // EarlyInitialization methods.
+  virtual void PreEarlyInitialization();
+  virtual void PostEarlyInitialization();
+
+  // PreMainMessageLoopStart methods.
+  virtual void PreMainMessageLoopStart();
+  virtual void PostMainMessageLoopStart();
+
+  // ToolkitInitialized methods.
+  virtual void ToolkitInitialized();
+
+  // MainMessageLoopRun methods.
+  virtual void PostBrowserProcessInit();
+  virtual void PostProfileInitialized();
+  virtual void PreMainMessageLoopRun();
+  virtual void PostMainMessageLoopRun();
+
+ private:
+  DISALLOW_COPY_AND_ASSIGN(ChromeBrowserParts);
+};
+
+#endif  // CHROME_BROWSER_CHROME_BROWSER_PARTS_H_