diff options
author | beng@google.com <beng@google.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2008-08-01 17:05:27 +0000 |
---|---|---|
committer | beng@google.com <beng@google.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2008-08-01 17:05:27 +0000 |
commit | a533eb4a0e924b8c0cab7a3964c127ce0d5f8185 (patch) | |
tree | 86c1755b210da306c6f0f938741e4c0c63039586 /chrome/browser/views/toolbar_view.cc | |
parent | cb4996397f1857ada4419fd166abf4567aa3556e (diff) | |
download | chromium_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/views/toolbar_view.cc')
-rw-r--r-- | chrome/browser/views/toolbar_view.cc | 5 |
1 files changed, 5 insertions, 0 deletions
diff --git a/chrome/browser/views/toolbar_view.cc b/chrome/browser/views/toolbar_view.cc index cc99296..056cbfe 100644 --- a/chrome/browser/views/toolbar_view.cc +++ b/chrome/browser/views/toolbar_view.cc @@ -343,6 +343,11 @@ void BrowserToolbarView::Layout() { page_menu_->GetY(), sz.cx, go_->GetHeight()); } +void BrowserToolbarView::DidChangeBounds(const CRect& previous, + const CRect& current) { + Layout(); +} + void BrowserToolbarView::DidGainFocus() { // Find first accessible child (-1 for start search at parent). int first_acc_child = GetNextAccessibleViewIndex(-1, false); |