1 files changed, 65 insertions, 0 deletions
diff --git a/chrome/browser/ui/cocoa/browser_frame_view.h b/chrome/browser/ui/cocoa/browser_frame_view.h
new file mode 100644
index 0000000..42faa9b
--- /dev/null
+++ b/chrome/browser/ui/cocoa/browser_frame_view.h
@@ -0,0 +1,65 @@
+// Copyright (c) 2009 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#import <Cocoa/Cocoa.h>
+
+// BrowserFrameView is a class whose methods we swizzle into NSGrayFrame
+// (an AppKit framework class) so that we can support custom frame drawing, and
+// have the ability to move our window widgets (close, zoom, miniaturize) where
+// we want them.
+// This class is never to be instantiated on its own.
+// We explored a variety of ways to support custom frame drawing and custom
+// window widgets.
+// Our requirements were:
+// a) that we could fall back on standard system drawing at any time for the
+//    "default theme"
+// b) We needed to be able to draw both a background pattern, and an overlay
+//    graphic, and we need to be able to set the pattern phase of our background
+//    window.
+// c) We had to be able to support "transparent" themes, so that you could see
+//    through to the underlying windows in places without the system theme
+//    getting in the way.
+// d) We had to support having the custom window controls moved down by a couple
+//    of pixels and rollovers, accessibility, etc. all had to work.
+//
+// Since we want "A" we couldn't just do a transparent borderless window. At
+// least I couldn't find the right combination of HITheme calls to make it draw
+// nicely, and I don't trust that the HITheme calls are going to exist in future
+// system versions.
+// "C" precluded us from inserting a view between the system frame and the
+// the content frame in Z order. To get the transparency we actually need to
+// replace the drawing of the system frame.
+// "D" required us to override _mouseInGroup to get our custom widget rollovers
+// drawing correctly. The widgets call _mouseInGroup on their superview to
+// decide whether they should draw in highlight mode or not.
+// "B" precluded us from just setting a background color on the window.
+//
+// Originally we tried overriding the private API +frameViewForStyleMask: to
+// add our own subclass of NSGrayView to our window. Turns out that if you
+// subclass NSGrayView it does not draw correctly when you call NSGrayView's
+// drawRect. It appears that NSGrayView's drawRect: method (and that of its
+// superclasses) do lots of "isMemberOfClass/isKindOfClass" calls, and if your
+// class is NOT an instance of NSGrayView (as opposed to a subclass of
+// NSGrayView) then the system drawing will not work correctly.
+//
+// Given all of the above, we found swizzling drawRect, and adding an
+// implementation of _mouseInGroup and updateTrackingAreas, in _load to be the
+// easiest and safest method of achieving our goals. We do the best we can to
+// check that everything is safe, and attempt to fallback gracefully if it is
+// not.
+@interface BrowserFrameView : NSView
+
+// Draws the window theme into the specified rect. Returns whether a theme was
+// drawn (whether incognito or full pattern theme; an overlay image doesn't
+// count).
++ (BOOL)drawWindowThemeInDirtyRect:(NSRect)dirtyRect
+                           forView:(NSView*)view
+                            bounds:(NSRect)bounds
+                            offset:(NSPoint)offset
+              forceBlackBackground:(BOOL)forceBlackBackground;
+
+// Gets the color to draw title text.
++ (NSColor*)titleColorForThemeView:(NSView*)view;
+
+@end