Widget::ShouldUseNativeFrame is now meaningful on Linux.

chrome/browser/ui/views/tabs/tab.h

Index: chrome/browser/ui/views/tabs/tab.h
diff --git a/chrome/browser/ui/views/tabs/tab.h b/chrome/browser/ui/views/tabs/tab.h
index 1f5083a3c264c33c5acff519d88e94559f17baea..ff282da673e92fb191ce6959c31a1bf47bd02451 100644
--- a/chrome/browser/ui/views/tabs/tab.h
+++ b/chrome/browser/ui/views/tabs/tab.h
@@ -243,6 +243,10 @@ class Tab : public gfx::AnimationDelegate,
   // Returns whether the Tab should display a close button.
   bool ShouldShowCloseBox() const;
 
+  // Returns true on Windows if the Glass styling is being used.
+  // This implies that the tab strip overlaps a native window frame.
+  bool UsingWindowsGlass(const views::Widget* widget) const;

[sky, 2014/02/03 21:53:03]

How about naming this ShouldUseGlassImages()? Also, make it static and have
TabStrip use this too.

[Matt Giuca, 2014/02/05 23:25:31]

I think this is different to the other methods above, because they dictate
whether a single particular thing should be shown. This function is really a
description of the environment, which is used in various ways (showing different
images, using different layout numbers, etc). In this case, it's more helpful to
name the function after what it tells you, than how you use it.
Done. (Note that if you follow this function all the way down, it calls a
virtual method whose override on Windows calls another virtual method whose
override on Windows calls a static function (IsAeroGlassEnabled); I am cutting
out all those middle-men and just directly calling IsAeroGlassEnabled.)

[sky, 2014/02/06 00:36:14]

Consider if we wanted to use this code on some other platform. In that case
UsingWindowsGlass isn't a good name. While technically UsingWindowsGlass is
correct now, the intention of this function is to decide where we use the
alternate set of images and layout. That's what I was hoping to capture with the
name ShouldUseGlassImages. Maybe ShouldUseGlassImagesAndLayout?

[Matt Giuca, 2014/02/07 09:13:11]

Well it's sort of moot now.

I've had to do a big refactor because I realised I was making a bad assumption:
that DesktopWindowTreeHostWin was a leaf class (and therefore I could inline
it's implementation of ShouldUseNativeFrame which just calls
IsAeroGlassEnabled). It actually has a subclass,
BrowserDesktopWindowTreeHostWin, which returns false if you have a themed window
open, even if Glass is enabled.

So I largely have to revert to the original design of calling through Widget to
ask whether it is a Glass window.

What I have done is added a new method called ShouldWindowContentsBeTransparent
to both Widget and DesktopWindowTreeHost. The intention is that it is true if
the window contents overhang the title bar, and then Tab, TabStrip and Toolbar
use that information to determine whether to use the Glass style of images and
layout.

I think this is the best solution -- it's almost identical to the original code
but it cleanly separates the transparency from the nativity. Another solution I
thought of was to have ShouldWindowContentsBeTransparent in
DesktopWindowTreeHost (but not Widget), and then from these classes, simply use
(ShouldUseNativeFrame() && IsAeroGlassEnabled()) to determine whether to use the
glass theming. That seemed messier to me.

Is this OK?

+
   // Gets the throb value for the tab. When a tab is not selected the
   // active background is drawn at |GetThrobValue()|%. This is used for hover,
   // mini tab title change and pulsing.