[linux_views][Win] spoof proof redesign infobar extension with tab.

chrome/browser/ui/views/infobars/infobar_container.h

Index: chrome/browser/ui/views/infobars/infobar_container.h
diff --git a/chrome/browser/ui/views/infobars/infobar_container.h b/chrome/browser/ui/views/infobars/infobar_container.h
index 071519267f8a8cce8ae46f2d4cede6efa69faafa..6c916a5b3e687ec9dba156dc6227c63025a0e531 100644
--- a/chrome/browser/ui/views/infobars/infobar_container.h
+++ b/chrome/browser/ui/views/infobars/infobar_container.h
@@ -34,9 +34,29 @@ class InfoBarContainer : public AccessiblePaneView,
     virtual ~Delegate();
   };
 
+  class Heights {

[Peter Kasting, 2011/03/04 22:23:42]

I think it would be clearer to write the InfoBarContainer and InfoBarView
classes without this class.

In my mind, what you want is these two API functions in both classes:
  int vertical_overlap();
  virtual gfx::Size GetPreferredSize();  // View override

InfoBarView::vertical_overlap() gives the current height of the top tab (i.e.
the tab's full height * the animation value).
InfoBarView::GetPreferredSize() gives the current size of the infobar including
the top tab.
InfoBarContainer::vertical_overlap() gives the vertical_overlap() of the first
child infobar.
InfoBarContainer::GetPreferredSize gives a size whose height is the sum of (for
all children, GetPreferredSize().height() - vertical_overlap()) plus
vertical_overlap().

This does not have a radical effect on the various callers, but I think it makes
things slightly clearer.  For example, the BrowserViewLayout code can be
slightly more direct.  This should also let you get rid of
InfoBarView::get_preferred_xxx_height(), I think.

[Sheridan Rawlins, 2011/03/05 18:06:54]

The reason for the class was that the layout code had to walk stuff and I didn't
want a bunch of routines all doing similar things for different reasons (laying
out, getting overlap, getting height).  Picking apart that concern lead me to a
LayoutHelper private method which does all three and simplifies by recursing
once when it needs to to set the |top| to the top of the toolbar separator.
I still like the preferred_xxx_height methods as private methods for all of the
internal calculations in InfoBarView for paths & clips.  In that context, it
seems more sensible to use the tab or bar height than doing calculations on the
full height and the vertical_overlap.

+   public:
+    Heights(int tab_height, int bar_height)
+        : tab_height_(tab_height),
+          bar_height_(bar_height) {}
+
+    int tab_height() const { return tab_height_; }
+    int bar_height() const { return bar_height_; }
+    int height() const { return tab_height_ + bar_height_; }
+
+   private:
+    friend class InfoBarContainer;
+
+    int tab_height_;
+    int bar_height_;
+  };
+
   explicit InfoBarContainer(Delegate* delegate);
   virtual ~InfoBarContainer();
 
+  // Return the tab and bar heights for this infobar container.
+  Heights GetHeights() const;
+
   // Changes the TabContents for which this container is showing infobars.  This
   // will remove all current infobars from the container, add the infobars from
   // |contents|, and show them all.  |contents| may be NULL.
@@ -57,13 +77,6 @@ class InfoBarContainer : public AccessiblePaneView,
   // hidden.
   void RemoveInfoBar(InfoBarView* infobar);
 
-  // Paint the InfoBar arrows on |canvas|. |arrow_center_x| indicates
-  // the desired location of the center of the arrow in the
-  // |outer_view| coordinate system.
-  void PaintInfoBarArrows(gfx::Canvas* canvas,
-                          View* outer_view,
-                          int arrow_center_x);
-
  private:
   typedef std::set<InfoBarView*> InfoBars;