Make GTK and Aura parts orthogonal to OS parts

content/browser/browser_main.h

 // 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 CONTENT_BROWSER_BROWSER_MAIN_H_
 #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"
 
 class BrowserThread;
 class CommandLine;
 class HighResolutionTimerManager;
 class MessageLoop;
 struct MainFunctionParams;
 
 namespace base {
 class SystemMonitor;
 }
 
 namespace net {
 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.
+//
+// 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
+//    specifc code (e.g. Gtk or Aura).

[DaveMoore, 2011/10/19 21:31:18]

Nit: spelling

 //  - 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).
 //
 // Parts:
 //  - EarlyInitialization: things which should be done as soon as possible on
 //    program start (such as setting up signal handlers) and things to be done
 //    at some generic time before the start of the main message loop.
 //  - MainMessageLoopStart: things beginning with the start of the main message
 //    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
 //    before/after your code is executed? Are there performance reasons for
 //    running your code at a particular time? Document these things!
 //  - Split out any platform-specific bits. Please avoid #ifdefs it at all
 //    possible. You have two choices for platform-specific code: (1) Execute it
 //    from one of the platform-specific |Pre/Post...()| methods; do this if the
 //    code is unique to a platform type. Or (2) execute it from one of the
 //    "parts" (e.g., |EarlyInitialization()|) and provide platform-specific
 //    implementations of your code (in a virtual method); do this if you need to
 //    provide different implementations across most/all platforms.
 //  - Unless your new code is just one or two lines, put it into a separate
 //    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 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();
   void MainMessageLoopStart();
   void RunMainMessageLoopParts();
 
   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();
 
   // Accessors for data members (below) ----------------------------------------
   const MainFunctionParams& parameters() const {
     return parameters_;
   }
   const CommandLine& parsed_command_line() const {
     return parsed_command_line_;
   }
   MessageLoop& main_message_loop() const {
     return *main_message_loop_;
   }
   void set_result_code(int result_code) { result_code_ = result_code; }
 
  private:
   void InitializeMainThread();
 
   // Members initialized on construction ---------------------------------------
 
   const MainFunctionParams& parameters_;
   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_;
   scoped_ptr<HighResolutionTimerManager> hi_res_timer_manager_;
   scoped_ptr<net::NetworkChangeNotifier> network_change_notifier_;
   scoped_ptr<BrowserThread> main_thread_;
 
   DISALLOW_COPY_AND_ASSIGN(BrowserMainParts);
 };
 
 bool ExitedMainMessageLoop();
 
 }  // namespace content
 
 CONTENT_EXPORT int BrowserMain(const MainFunctionParams& parameters);
 
 #endif  // CONTENT_BROWSER_BROWSER_MAIN_H_