Make GTK and Aura parts orthogonal to OS parts

content/browser/browser_main.h

Index: content/browser/browser_main.h
diff --git a/content/browser/browser_main.h b/content/browser/browser_main.h
index ec1121fec7792995fe79384a59175f05a2606dfa..b3eca234e822546bff50a3bff6acd9ad99061fe8 100644
--- a/content/browser/browser_main.h
+++ b/content/browser/browser_main.h
@@ -6,6 +6,8 @@
 #define CONTENT_BROWSER_BROWSER_MAIN_H_
 #pragma once
 
+#include <vector>
+
 #include "base/basictypes.h"
 #include "base/memory/scoped_ptr.h"
 #include "content/common/content_export.h"
@@ -26,18 +28,32 @@ class NetworkChangeNotifier;
 
 namespace content {
 
-// BrowserMainParts:
-// This class contains different "stages" to be executed in |BrowserMain()|,
-// mostly initialization. This is made into a class rather than just functions
-// so each stage can create and maintain state. Each part is represented by a
-// single method (e.g., "EarlyInitialization()"), which does the following:
+// These classes contains singleton member variables specific to the browser
+// process, and virtual methods representing different "stages" to be executed
+// from |BrowserMain()|, mostly to do initialization and shutdown.
+//
+// There are two types of "Parts":
+// * BrowserMainParts : There must be exactly one instance derived from this
+//   class. It can override any of the BrowserParts methods, in addition to
+//   MainMessageLoopRun() and other "main" methods.
+// * BrowserParts: There can be any number of additional "Parts" added to
+//   the BrowserMainParts instance with AddParts(). Each stage will be called
+//   for these parts in the order they were added. Destruction is in the
+//   inverse order.

[jam, 2011/10/20 18:01:19]

While I understand why you did it, the concept of having two different types of
parts, one which we can have many of, and one only one instance, is a little
confusing to me.

Did you consider just having all instances be of the same type? And then when we
call RunMainMessageLoopParts on all the instances, obviously only the first part
which accepts to run it gets a go, and we don't call any of the rest.

[stevenjb, 2011/10/21 22:25:49]

After some conversation and a closer look at browser_main.h, I realized that:
* most of the original BrowserMainParts could be pulled into the .cc file (now
BrowserMainLoop)
* BrowserParts should be restored to BrowserMainParts as a pure interface class
and moved into public/browser/browser_main_parts.h
* MainMessageLoopRun() should be in the new BrowserMainParts and return a bool
if it runs the main loop

+//
+// Each stage is represented by a single BrowserMainParts method
+// (e.g., "EarlyInitialization()"), which does the following:
 //  - calls a method (e.g., "PreEarlyInitialization()") which individual
 //    platforms can override to provide platform-specific code which is to be
 //    executed before the common code;
+//  - calls the Pre method on the list of added parts to do additional component
+//    specific code (e.g. Gtk or Aura).
 //  - calls various methods for things common to all platforms (for that given
-//    stage); and
+//    stage)
 //  - calls a method (e.g., "PostEarlyInitialization()") for platform-specific
 //    code to be called after the common code.
+// -- calls the Post method for added parts.
+//
 // As indicated above, platforms should override the default "Pre...()" and
 // "Post...()" methods when necessary; they need not call the superclass's
 // implementation (which is empty).
@@ -50,7 +66,8 @@ namespace content {
 //    loop and ending with initialization of the main thread; platform-specific
 //    things which should be done immediately before the start of the main
 //    message loop should go in |PreMainMessageLoopStart()|.
-//  - (more to come)
+//  - RunMainMessageLoopParts:  things to be done before and after invoking the
+//    main message loop run method (e.g. MessageLoopForUI::current()->Run()).
 //
 // How to add stuff (to existing parts):
 //  - Figure out when your new code should be executed. What must happen
@@ -67,11 +84,30 @@ namespace content {
 //    method with a well-defined purpose. (Likewise, if you're adding to an
 //    existing chunk which makes it longer than one or two lines, please move
 //    the code out into a separate method.)
-class CONTENT_EXPORT BrowserMainParts {
+
+class CONTENT_EXPORT BrowserParts {
+ public:
+  virtual ~BrowserParts();
+
+  virtual void PreEarlyInitialization();
+  virtual void PostEarlyInitialization();
+  virtual void PreMainMessageLoopStart();
+  virtual void PostMainMessageLoopStart();
+  virtual void PreMainMessageLoopRun();
+  virtual void PostMainMessageLoopRun();
+};
+
+// This is a required implementation of BrowserParts. Override this to provide
+// application specific behavior. There can only be one implementation of
+// BrowserMainParts.
+class CONTENT_EXPORT BrowserMainParts : public BrowserParts {
  public:
   explicit BrowserMainParts(const MainFunctionParams& parameters);
   virtual ~BrowserMainParts();
 
+  // Adds an additional BrowserParts instance.
+  virtual void AddParts(BrowserParts* parts);
+
   // Parts to be called by |BrowserMain()|.
   void EarlyInitialization();
   void InitializeToolkit();
@@ -81,15 +117,9 @@ class CONTENT_EXPORT BrowserMainParts {
   int result_code() const { return result_code_; }
 
  protected:
-  // Methods to be overridden to provide platform-specific code; these
-  // correspond to the "parts" above.
-  virtual void PreEarlyInitialization();
-  virtual void PostEarlyInitialization();
-  virtual void PreMainMessageLoopStart();
-  virtual void PostMainMessageLoopStart();
-  virtual void PreMainMessageLoopRun();
+  // Run main message loop. Invokes MessageLoopForUI::current()->Run unless
+  // overridden.
   virtual void MainMessageLoopRun();
-  virtual void PostMainMessageLoopRun();
 
   // Allows an embedder to do any extra toolkit initialization.
   virtual void ToolkitInitialized();
@@ -115,6 +145,12 @@ class CONTENT_EXPORT BrowserMainParts {
   const CommandLine& parsed_command_line_;
   int result_code_;
 
+  // Vector of extra parts added by AddParts after construction ----------------
+  // The BrowserParts fucntions for each part are called in the order added.
+  // They are released (destroyed) in the reverse order.
+  typedef std::vector<BrowserParts*> PartsList;
+  PartsList added_parts_;
+
   // Members initialized in |MainMessageLoopStart()| ---------------------------
   scoped_ptr<MessageLoop> main_message_loop_;
   scoped_ptr<base::SystemMonitor> system_monitor_;
@@ -132,3 +168,8 @@ bool ExitedMainMessageLoop();
 CONTENT_EXPORT int BrowserMain(const MainFunctionParams& parameters);
 
 #endif  // CONTENT_BROWSER_BROWSER_MAIN_H_
+
+//  LocalWords:  BrowserMain BrowserMainParts BrowserParts MainMessageLoopRun
+//  LocalWords:  AddParts EarlyInitialization PreEarlyInitialization Pre Gtk
+//  LocalWords:  PostEarlyInitialization superclass's MainMessageLoopStart
+//  LocalWords:  PreMainMessageLoopStart RunMainMessageLoopParts ifdefs