summaryrefslogtreecommitdiffstats
path: root/chrome/browser/browser_window.h
diff options
context:
space:
mode:
authorbeng@google.com <beng@google.com@0039d316-1c4b-4281-b951-d872f2087c98>2008-08-01 17:05:27 +0000
committerbeng@google.com <beng@google.com@0039d316-1c4b-4281-b951-d872f2087c98>2008-08-01 17:05:27 +0000
commita533eb4a0e924b8c0cab7a3964c127ce0d5f8185 (patch)
tree86c1755b210da306c6f0f938741e4c0c63039586 /chrome/browser/browser_window.h
parentcb4996397f1857ada4419fd166abf4567aa3556e (diff)
downloadchromium_src-a533eb4a0e924b8c0cab7a3964c127ce0d5f8185.zip
chromium_src-a533eb4a0e924b8c0cab7a3964c127ce0d5f8185.tar.gz
chromium_src-a533eb4a0e924b8c0cab7a3964c127ce0d5f8185.tar.bz2
Adds the BrowserView to the XPFrame/VistaFrame, and moves the BrowserToolbarView and StatusBubble into it.
Also restructures the creation of the Frame. This is significant! The Browser now constructs a frame via a new static BrowserWindow::CreateBrowserWindow method (see browser_window_factory.cc). Recall the diagram in the architectural overview doc - the BrowserView object is the one that implements the interface that the Browser object uses to communicate with the UI. The Browser object communicates to the BrowserView directly through this interface, but not directly to the frame. What actually happens right now in CreateBrowserWindow is that an XP/VistaFrame is constructed, but this is _not_ the object returned to the Browser, rather when the XP/VistaFrame is init'ed, it constructs a BrowserView that also implements BrowserWindow. This is the object that's returned to the Browser. Since both BrowserView and XP/VistaFrame implement BrowserWindow, I am now able to gradually migrate functionality from the frames to BrowserView. During this process BrowserWindow functions not handled yet by BrowserView will be forwarded to the appropriate frame. Modifies the Accessibility UI tests to account for this extra level of indirection (should only be temporary while I'm moving things around). This does actually pass the UI tests. See the whiteboard in my office for a diagram. This is a bit confusing right now since there's so much going on. Sadly the only way to get where we need to go incrementally is to make a mess on the way. B=1031854 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@245 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/browser/browser_window.h')
-rw-r--r--chrome/browser/browser_window.h15
1 files changed, 12 insertions, 3 deletions
diff --git a/chrome/browser/browser_window.h b/chrome/browser/browser_window.h
index 713618a..10a173c 100644
--- a/chrome/browser/browser_window.h
+++ b/chrome/browser/browser_window.h
@@ -37,7 +37,9 @@
#include "chrome/views/accelerator.h"
class BookmarkBarView;
+class Browser;
class BrowserList;
+class BrowserView;
namespace ChromeViews {
class RootView;
}
@@ -158,9 +160,6 @@ class BrowserWindow {
// |content_rect|.
virtual gfx::Rect GetBoundsForContentBounds(const gfx::Rect content_rect) = 0;
- // Set the frame bounds. |bounds| is in screen coordinate.
- virtual void SetBounds(const gfx::Rect& bounds) = 0;
-
// Tel this frame to detach from the web browser. The frame should no longer
// notify the browser about anything.
virtual void DetachFromBrowser() = 0;
@@ -191,6 +190,10 @@ class BrowserWindow {
// Returns the Bookmark Bar view.
virtual BookmarkBarView* GetBookmarkBarView() = 0;
+ // Returns the BrowserView.
+ // TODO(beng): remove this! temporary only!
+ virtual BrowserView* GetBrowserView() const = 0;
+
// Updates the toolbar with the state for the specified |contents|.
virtual void Update(TabContents* contents, bool should_restore_state) = 0;
@@ -200,8 +203,14 @@ class BrowserWindow {
// Focuses the toolbar (for accessibility).
virtual void FocusToolbar() = 0;
+ // Construct a BrowserWindow implementation for the specified |browser|.
+ static BrowserWindow* CreateBrowserWindow(Browser* browser,
+ const gfx::Rect& bounds,
+ int show_command);
+
protected:
friend class BrowserList;
+ friend class BrowserView;
virtual void DestroyBrowser() = 0;
};