Support DWM switching....

Support DWM switching.

This completes the collapsing of window types and browser frames around a single class: views::Window. CustomFrameWindow is removed with this change.

The Browser window is represented by a single views::Window subclass: BrowserFrame, which replaces both AeroGlassFrame and OpaqueFrame.

NonClientView is now a container of two sibling classes - the Window's ClientView (in the Browser's case, BrowserView), and a NonClientFrameView subclass, which provides the rendering for the non-client portions of the window. These Views are siblings rather than the ClientView a child of the NonClientFrameView because when the DWM is toggled, the ClientView would have to be re-parented. Many Views make the assumption they are only inserted into a View hierarchy once, and so this is problematic. By having the views be siblings, this is avoided.

With this in mind, all of the former NonClientViews now become NonClientFrameView subclasses:

DefaultNonClientView -> CustomFrameView
(non-existent, NonClientView) -> NativeFrameView
AeroGlassNonClientView -> GlassBrowserFrameView
OpaqueNonClientView -> OpaqueBrowserFrameView

The latter two derive from NonClientFrameView via BrowserNonClientFrameView, which adds some extras.

I also had to modify the TabRenderer class to know how to drop its cache of tab background images when the theme changes since it uses different ones for Glass and non-Glass.

This change also fixes a few non-client flicker issues relating to window non-client activation by using more ScopedRedrawLocks. (Touches info_bubble.cc, window.cc)

Bugs fixed:
http://crbug.com/153
http://crbug.com/747
http://crbug.com/2371
http://crbug.com/3264
http://crbug.com/8234
Plumbing for http://crbug.com/8247

Design docs:
http://dev.chromium.org/developers/design-documents/views-windowing
http://dev.chromium.org/developers/design-documents/browser-window


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=10757

[Elliot Glaysher, 2009-03-02 22:00:37]

http://codereview.chromium.org/27317/diff/3023/2050
File chrome/views/non_client_view.cc (right):

http://codereview.chromium.org/27317/diff/3023/2050#newcode16
Line 16: // The frame view and the client view are always at these specific
indices.
WHY?

http://codereview.chromium.org/27317/diff/3023/2050#newcode80
Line 80: bool always_use_custom_frame =
Comment about constrained windows always needing this?

http://codereview.chromium.org/27317/diff/3023/2050#newcode145
Line 145: // Add our Client View as we are added to the Widget so that if we are
Update comment?

http://codereview.chromium.org/27317/diff/3023/2049
File chrome/views/non_client_view.h (right):

http://codereview.chromium.org/27317/diff/3023/2049#newcode48
Line 48: virtual gfx::Rect GetWindowBoundsForClientBounds(
Comments?

http://codereview.chromium.org/27317/diff/3023/2049#newcode127
Line 127: void SetCustomFrameView(NonClientFrameView* custom_frame_view);
Removed?

http://codereview.chromium.org/27317/diff/3023/2049#newcode210
Line 210: scoped_ptr<NonClientFrameView> frame_view_;
Might want to mention why this isn't owned by the Views.

http://codereview.chromium.org/27317/diff/3023/2049#newcode212
Line 212: // Whether or not we should use the native frame. Applies to all
windows.
Wrong?

http://codereview.chromium.org/27317/diff/3023/2042
File chrome/views/root_view.h (right):

http://codereview.chromium.org/27317/diff/3023/2042#newcode88
Line 88: void ThemeChanged();
Should state virtual?

[Elliot Glaysher, 2009-03-03 00:05:36]

LGTM after those changes.